[OGSA-AUTHZ] Next Telecon

Wed Nov 1 17:26:59 CST 2006

David,

I'm not sure I fully understand this proposal, but a couple of things came to mind. Hope you find these comments useful.

> Each of these 3 interfaces could be APIs or open protocols.

I think it would be a good idea to clarify if the WG plans to produce APIs, protocols, or both. One typically doesn't find the same data encodings used in protocol wire-formats and APIs.

> 1. PEP-Context Handler.  PEP→CH, the authenticated name of 
> the user, the credentials of the user (optional) and the 
> user’s access request.
> CH→PEP, the authorization decision.
> 
> 2. Context Handler-CVS. CH→CVS, the authenticated name of the 
> user, the credentials of the user (optional). CVS→CH, the 
> validated attributes of the user.
> 
> 3. Context Handler-PDP. CH→PDP, the authenticated name of the 
> user, the validated attributes of the user and the user’s 
> access request. PDP→CH, the authorization decision.
> 
> If credentials can be packaged as attributes, then only two 
> protocols need to be standardised, namely 1/3 and 2.

I believe you're saying you want to treat 'validated attributes' and credentials the same way for all 3 APIs/protocols? This may be all right in this context, but one should ask if this beneficial for implementors. I haven't fully thought this through, but it might increase decoding and error handling complexity.

The proposal suggests 'tunneling' of SAML credentials inside a SAML attribute. You'd need to clearly specify the processing rules. For example, if the endpoint is expecting user attributes and receive a SAML credential are they supposed to decode the credential and pull out any included attributes?

Finally, your mail seems to indicate a need to define, and get agreement on, new SAML attribute types. Adopting the WS* defined approach for security token encoding may be an easier path.

Regards,
Blair Dillaway

> -----Original Message-----
> From: ogsa-authz-wg-bounces at ogf.org 
> [mailto:ogsa-authz-wg-bounces at ogf.org] On Behalf Of David Chadwick
> Sent: Tuesday, October 31, 2006 3:57 AM
> To: OGSA AUTHZ WG
> Subject: [OGSA-AUTHZ] Next Telecon
> 
> Dear WG
> 
> the next telecon is scheduled for Wed 8 November. I believe 
> that the "Functional Components of Grid Service Provider 
> Authorisation Service Middleware" document is now complete. I 
> would us like to confirm that we are broadly happy with this 
> model at the telecon, and then move onto the more important 
> work, which is to define the protocols/profiles necessary to 
> implement this model. The latest document describes three 
> interfaces that are candidates for standardisation, namely:
> 
> 1. one for the context handler talking to the PEP,
> 
> 2. a second for the context handler talking to the CVS and
> 
> 3. a third for the context handler talking to the PDP.
> 
> Each of these 3 interfaces could be APIs or open protocols. 
> As specified in the Functional Components document, the 
> functionality required of the three interfaces is as follows:
> 
> 1. PEP-Context Handler.  PEP→CH, the authenticated name of 
> the user, the credentials of the user (optional) and the 
> user’s access request.
> CH→PEP, the authorization decision.
> 
> 2. Context Handler-CVS. CH→CVS, the authenticated name of the 
> user, the credentials of the user (optional). CVS→CH, the 
> validated attributes of the user.
> 
> 3. Context Handler-PDP. CH→PDP, the authenticated name of the 
> user, the validated attributes of the user and the user’s 
> access request. PDP→CH, the authorization decision.
> 
> I would like to make the following proposal for discussion at 
> the next telecon.
> 
> If credentials can be packaged as attributes, then only two 
> protocols need to be standardised, namely 1/3 and 2.
> 
> This is not so radical. It is already a feature of our 
> existing SAML profile, and it has been successfully 
> implemented by at least 4 implementations that I know of (GT, 
> Permis, Primea, OMII(UK)). So I dont see any problem in this.
> 
> Here is how it works.
> 
> In XACML, an attribute is currently defined as an attribute 
> ID, a data type and a value. The contents of all 3 are 
> transparent to the protocol and are carried as XML strings. 
> So essentially they can contain anything. When we package a 
> credential as an attribute, we simply define a new attribute 
> ID and data type to represent the credential and the value is 
> then the string encoding of the credential.
> 
> So to pass the following within the same protocol as 
> attributes we do the following.
> 
> 1. An Attribute, e.g.
> AT ID=role DT=string AV=student, sent as usual with no 
> modifications <Attribute 
> AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
>              DataType="http://www.w3.org/2001/XMLSchema#string">
>    <AttributeValue>student</AttributeValue>
>   </Attribute>
> 
> 2. An X.509 attribute certificate credential in which AT 
> ID=X.509AC DT=BER AV=<some BER>, AT is sent as <Attribute 
> AttributeId="://www.ieft.org/rfc/rfc2256.txt#
> attributeCertificateAttribute"
> the value is base64 encoded into a string, and the DT is 
> either string or Base64 string (if this exists)
> 
> 3. A SAML Attribute Assertion credential AT ID=SAML Attribute 
> Assertion DT=XML AV=<SAML AA XML>, we need to define an 
> attribute ID for a SAML Attribute Assertion (unless this 
> already exists), the DT is string, and then we send the value 
> enclosed in speech marks " "
> 
> 4. An X.509 Public Key certificate with Subject Directory 
> Attributes credential. Send in the same way as an X.509 AC, 
> except that ID is userCertificate.
> 
> I should like the above to form a major topic for discussion 
> at the telecon. If we can agree on this, it makes the 
> standardisation work 30% easier!!
> 
> regards
> 
> David
> 
> 
> 
> 
> *****************************************************************
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security The Computing 
> Laboratory, University of Kent, Canterbury, CT2 7NF Skype 
> Name: davidwchadwick
> Tel: +44 1227 82 3221
> Fax +44 1227 762 811
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick at kent.ac.uk
> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
> Research Web site: http://sec.cs.kent.ac.uk Entrust key 
> validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5
> 
> *****************************************************************
> --
>   ogsa-authz-wg mailing list
>   ogsa-authz-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
> 