On 10/31/06, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
I believe that the "Functional Components of Grid Service Provider Authorisation Service Middleware" document is now complete.
Sorry I haven't provided feedback previously since I'm just now coming to grips with this document (which uses some terminology foreign to me). As far as I can tell, there really are only two models, represented by Figures 1 and 2. Figures 3 and 4 don't really add anything new to the model. I think the PEP needs to (optionally) provide the following additional data to the context handler (who in turn passes it on to the CVS): - the unique identifier (entityID) of the Identity Provider that exposes the AA - the SAML Subject to use as a query subject These quantities might be bound to the certificate used to authenticate to the PEP, in the SIA extension and Subject Alt Name extension, respectively. See the following discussion thread for more information along these lines: http://www.globus.org/mail_archive/gridshib-dev/2006/10/msg00004.html
If credentials can be packaged as attributes, then only two protocols need to be standardised, namely 1/3 and 2.
I don't understand. Can you explain this a bit more?
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.
Does the "SAML 2.0 profile of XACML v2.0" apply?
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 " "
Are you suggesting that SAML attributes be repackaged as XACML attributes? (The "SAML 2.0 profile of XACML v2.0" profiles exactly this, btw.) At what step of the flow will this mapping occur?
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.
Thanks, Tom