[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