[OGSA-AUTHZ] WG Last Call: Use of SAML for OGSA Authorization

[Oleksandr Otenko]

Markus Lorch wrote:
> Von and others,
> 
> I was originally hoping that we may have obligations defined
> in this version but have been convinced by the arguments presented
> by others on the list that we should go ahead and finalize
> the May version without the addition on new features first.
> 
> One note on the Advice extension point (5.1.1	Element <
> AuthorizationAdvice>): 
> 
> When coding additional advice types that utilize this 
> extension points I noticed that, at least in the existing 
> prototype implementation within GT3.3, it requires changes 
> to the low layer parser for the ExtendedAuthorizationDecisionQuery.
> 
> I think this is due to the fact that AuthoizationAdvice is 
> an abstract type for which instantiations of AuthorizationAdvice
> change the tag name to e.g. SubjectAttributeReferenceAdvice and
> this tag name thus has to be recognized directly by the
> parser that reads the ExtendedAuthorizationDecisionQuery.

I think if you write the schema properly, the parser will recognize that 
SubjectAttributeReferenceAdvice extends AuthorizationAdvice, and 
therefore is allowed instead of the latter. I am not sure what the 
situation is with the schema used by ExtendedAuthorizationDecisionQuery.


Sassa

> 
> Would it be a more scalable/extensible approach to have an
> base-Element called "AuthorizationAdvice" with a minimal general
> structure which could be extended by specific Advice implementations
> without chaning the Element tag name within the
> ExtendedAuthorizationDecisionQuery.
> This would allow a parser for ExtendedAuthorizationDecisionQuery
> to parse through the query without having been armed with all the
> code that would anticipate every single possible advice implementation.
> I.e., adding one more level of redirection to facilitate that somebody
> who wants to extend by adding a new advice doesn't have to
> modify the parser for ExtendedAuthorizationDecisionQuery. 
> 
> It may well be possible that it could be coded this way with the
> existing definition but I just don't know how. I will be happy 
> to learn about the appropiate way of implementing such an 
> extension point. 
> 
> Markus 
> 
> 
>>-----Original Message-----
>>From: owner-ogsa-authz at ggf.org 
>>[mailto:owner-ogsa-authz at ggf.org] On Behalf Of Von Welch
>>Sent: Dienstag, 14. Dezember 2004 19:41
>>To: ogsa-authz at gridforum.org
>>Subject: [OGSA-AUTHZ] WG Last Call: Use of SAML for OGSA Authorization
>>
>>
>>
>>I am putting the document "Use of SAML for OGSA Authorization" into
>>working group last call. Please send any comments to the group list
>>by January 10th.
>>
>>As discussed at GGF12, I have taken the May 14th version (prior to
>>the Obligations work) made the changes indicated at the end of the
>>email. The resulting document is dated December 14th and can be found
>>in Grid Forge, or directly using the URL appended below.
>>
>>I understand that at least one group member wanted to get Obligations
>>into this document, but I believe this document captures a vital
>>snapshot of implementations in its own right and should be move
>>forward. It can be followed by another version with Obligations. Those
>>feeling strongly about this are encouraged to indicated to the working
>>group as part of the Last Call process.
>>
>>I expect to follow this with a Last Call on the Attributes document
>>shortly.
>>
>>Von
>>
>>Word version:
>>https://forge.gridforum.org/docman2/ViewProperties.php?group_i
> 
> d=119&category_id=450&document_content_id=3227
> 
> PDF version:
> https://forge.gridforum.org/docman2/ViewProperties.php?group_id=119&category
> _id=450&document_content_id=3228
> 
> Changes from May, 2004 to December, 2004 version:
> 
>  * Added Appendix C giving an example of how GT4 creates URIs from
>  WS-Addressing elements.
> 
>  * Marked Recipient field in 5.1 as depreciated since it is
>  insufficient to stop replay attacks.
> 
> 
>