[OGSA-AUTHZ] Next Telecon

David Chadwick d.w.chadwick at kent.ac.uk
Thu Nov 2 04:28:45 CST 2006 

Hi Blair

Blair Dillaway wrote:
> David,
> 
> I'm not sure I fully understand this proposal, but a couple of things
> came to mind. Hope you find these comments useful.
> 
>> Each of these 3 interfaces could be APIs or open protocols.
> 
> I think it would be a good idea to clarify if the WG plans to produce
> APIs, protocols, or both. One typically doesn't find the same data
> encodings used in protocol wire-formats and APIs.

My understanding is that the Globus team have agreed to produce 
documentation of their Java APIs, which will correspond approximately to 
2 of these interfaces. How close the match is can be judged once we see 
the documentation.

The WG will produce the protocol specs for the interfaces using open 
protocols.

> 
>> 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.
>> 
>> If credentials can be packaged as attributes, then only two 
>> protocols need to be standardised, namely 1/3 and 2.
> 
> I believe you're saying you want to treat 'validated attributes' and
> credentials the same way for all 3 APIs/protocols? 

I am suggesting that they can packaged in the same way so that they can 
pass through the protocols transparently. But the receiver will need to 
treat them in different ways by looking at their "type".

The alternative to this is to define 3 separate protocols. There can be 
some discussion about which is preferred, many protocols with tiny 
scope, or fewer protocols with larger scope. It seems to me that the 
Http/SOAP approach favours the latter.


This may be all
> right in this context, but one should ask if this beneficial for
> implementors. I haven't fully thought this through, but it might
> increase decoding and error handling complexity.

We have already implemented this so we have some experience of how it 
works. Basically the receiver needs to look at the attribute "types" to 
determine how to handle them, so its not a big deal. For example, we can 
receive either X.509 ACs or text attributes from a Shibboleth IdP and 
can pass them on the PDP/CVS appropriately.

> 
> The proposal suggests 'tunneling' of SAML credentials inside a SAML
> attribute. You'd need to clearly specify the processing rules.

Agreed.

For
> example, if the endpoint is expecting user attributes and receive a
> SAML credential are they supposed to decode the credential and pull
> out any included attributes?

Yes. But they can do this by simply relaying them to a CVS.

> 
> Finally, your mail seems to indicate a need to define, and get
> agreement on, new SAML attribute types. Adopting the WS* defined
> approach for security token encoding may be an easier path.

Actually I am not that concerned how the difference between a credential 
or attribute is flagged, just that it can be, so that the receiver 
knows. So if WS* can do it more effectively, that is fine by me.

regards

David


> 
> Regards, Blair Dillaway
> 
> 
>> -----Original Message----- From: ogsa-authz-wg-bounces at ogf.org 
>> [mailto:ogsa-authz-wg-bounces at ogf.org] On Behalf Of David Chadwick 
>> Sent: Tuesday, October 31, 2006 3:57 AM To: OGSA AUTHZ WG Subject:
>> [OGSA-AUTHZ] Next Telecon
>> 
>> 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
>> 
>> ***************************************************************** 
>> -- ogsa-authz-wg mailing list ogsa-authz-wg at ogf.org 
>> http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
>> 

-- 

*****************************************************************
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