OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Action Items.


Title: RE: Contradictory requirements?
At the focus I said I would provide a rationale for the query and assertion structures, however during the conference call thinking on the query structure appeared to go in a different direction and so instead I will provide the rationale for the query structure that appeared to be suggested at the meeting.
 
Principles:
 
1) You only get what you ask for
So if you ask for an Attribute assertion you should not recieve back an Authorization Assertion.
 
2) Support different toplevel query elements for each of the assertion issuer types.
The main advantage of this is that it allows a service to advertise that it supports Authorization Assertions by means of WSDL like description.
 
3) Support legacy applications
It is essential that an existing legacy authorization engine be able to support SAML without major revision to the code.
 
4) Permit some level of formal definition
Although we will not specify the implementation architecture we may specify the behaviors of the system by specifying the XQuery equivalents of the supported queries
 
5) Allow for extensibility
Actually this comes for free with the Web Services type approach. A service can always provide an enhanced query interface - e.g. full XQuery.
 
 
Of these principles, the one that has the most impact is 3 since it encourages a minimalist 'slot filling' type query approach. In each case a SAML. One of the notable features of the SAML application is that in each case the query is directed at a specific subject. This coupled with the separate toplevel types criteria suggests the following structure:
 
SAMLQuery  [Abstract]
    -> SAMLSubjectQuery [Abstract]
        -> SAMLAuthenticationQuery
        -> SAMLAuthorizationQuery
        -> SAMLAttributeQuery
  [ -> SAMLXQuery ]   (when XQuery is specified)
 
The two abstract types could be compounded into one, however this would allow for less extensibility, an XQuery interface would logically plug into the SAMLQuery slot. Equally, XACML policy queries would likely have a resource as the base rather than a subject.
 
The SAMLAuthenticationQuery does not appear to require additional data.
 
The SAMLAuthorizationQuery requires the resource for which the authorization is requested to be specified.
 
The SAMLAttributeQuery requires some means of identifying the specific attributes that are of interest. The subject provides part of the scope for the query since the issuer should only be returning attributes that relate to that issuer. The requestor could specify the specific attributes that are of interest, potentially the resource to which access is requested might direct the query.
 
I suspect that the AttributeQuery will require some degree of wildcarding. Consider the case in which we are asking for the subject credit limit. Do we have to make individual queries for credit limits for $50, $100, ... etc. Clearly some form of wildcarding is inevitable and will occur whether it is explicitly supported by the spec or users develop their own conventions.
 
I will sketch out some XMLSchema to support this and issue a core09 draft by COB today.
 
        Phill
 
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

Phillip Hallam-Baker (E-mail).vcf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC