Hi Blair Blair Dillaway wrote:
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.
My understanding is that the Globus team have agreed to produce documentation of their Java APIs, which will correspond approximately to 2 of these interfaces. How close the match is can be judged once we see the documentation. The WG will produce the protocol specs for the interfaces using open protocols.
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?
I am suggesting that they can packaged in the same way so that they can pass through the protocols transparently. But the receiver will need to treat them in different ways by looking at their "type". The alternative to this is to define 3 separate protocols. There can be some discussion about which is preferred, many protocols with tiny scope, or fewer protocols with larger scope. It seems to me that the Http/SOAP approach favours the latter. 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.
We have already implemented this so we have some experience of how it works. Basically the receiver needs to look at the attribute "types" to determine how to handle them, so its not a big deal. For example, we can receive either X.509 ACs or text attributes from a Shibboleth IdP and can pass them on the PDP/CVS appropriately.
The proposal suggests 'tunneling' of SAML credentials inside a SAML attribute. You'd need to clearly specify the processing rules.
Agreed. 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?
Yes. But they can do this by simply relaying them to a CVS.
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.
Actually I am not that concerned how the difference between a credential or attribute is flagged, just that it can be, so that the receiver knows. So if WS* can do it more effectively, that is fine by me. regards David
Regards, Blair Dillaway
-----Original Message----- From: ogsa-authz-wg-bounces@ogf.org [mailto:ogsa-authz-wg-bounces@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@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
-- ***************************************************************** 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@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 *****************************************************************