[OGSA-AUTHZ] Next Telecon

Wed Nov 8 06:19:37 CST 2006

Hi David,

Unfortunately I was able to read all discussion only now just to prepare 
to the telecon.

But nevertheless, I'd like to give some comments on your major
topic/question for this telecon regarding protocols.

David Chadwick wrote:
> 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 have a problem, from the design point of view, to understand if we
need separate interfaces with the CH in the middle as a separate entity.

I'd rather see CH as a set of interfaces between major/generic AuthZ
functional modules:

PEP - PDP => CH1.1
PEP - CVS => CH1.2

PDP - PEP => CH2.1
PDP - CVS => CH2.2

If we define e.g. (PDP - CH) + (CH - PEP) and so on, I see a need to
possible define stateful CH model was probably not an initial goal and
it doesn't reflect current practice.

> 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.
> 
With the definition of the CH as a set of transparent interfaces, I
think it is resolved.

CHx as an interface between major modules may apply some filtering what
information to resolve, remove or add. But this should up to the CHx
implementation which may be specific for every pair of different types
of PEP, PDP and CVS modules.

> 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.
> 
This was also my understanding about current practice.

> Here is how it works.
> 
I completely agree with your explanation and proposal about mapping and
repackaging between SAML and XACML attributes. I checked this with the
XACML schema and see no problem.

I also agree with most of your comments re SAML/XACML in discussion with
Tom. But I will look closer if some unclear for me.

Regards,

Yuri

> 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