Hi Tom Tom Scavo wrote:
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.
Well they show the difference between the push and pull modes of operation. This is actually quite a big difference in terms of usability, client complexity, privacy, etc. But its nice that you see the similarities between the two modes, because we can utilize this in the protocols that we eventually standardise :-)
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
Now why would that be important? More important than the IDP ID is surely the AA contact details, especially for the pull model (unless you are equating the two as being the same thing?). We have included the latter in the existing SAML1.1 profile, as a URL, and can add it to the current spec as well.
- the SAML Subject to use as a query subject
this is conceptually the authenticated name in the diagrams. It can be encoded as a SAML Subject if you wish. This is just detail. (I see below that this is the subject alt name anyway, so we agree on this)
These quantities might be bound to the certificate used to authenticate to the PEP, in the SIA extension
Conceptually SIA is probably the right field to insert details of where to get subject attributes from. 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?
I thought I had done. Was it not enough?
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?
Yes, this is what I already use in the draft profiles published earlier this year
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?
Yes exactly that. (Well actually that SAML attribute assertions be repackaged as XACML attributes). The function of the CVS is to validate the SAML assertions. (The "SAML 2.0 profile of XACML v2.0" profiles exactly
this, btw.) At what step of the flow will this mapping occur?
Inside the CVS, when it checks any signature on the assertion, who the issuer was, what the validity time is etc. regards David
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
-- ***************************************************************** 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 *****************************************************************