[OGSA-AUTHZ] Next Telecon

David Chadwick d.w.chadwick at kent.ac.uk
Tue Oct 31 05:56:41 CST 2006


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

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


More information about the ogsa-authz-wg mailing list