[OGSA-AUTHZ] Next Telecon

[David Chadwick]

Hi Tom

Tom Scavo wrote:
> On 10/31/06, David Chadwick <d.w.chadwick at 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 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

*****************************************************************