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@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 *****************************************************************
On 10/31/06, David Chadwick <d.w.chadwick@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. 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 - the SAML Subject to use as a query subject These quantities might be bound to the certificate used to authenticate to the PEP, in the SIA extension 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?
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?
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? (The "SAML 2.0 profile of XACML v2.0" profiles exactly this, btw.) At what step of the flow will this mapping occur?
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
Hi Tom Tom Scavo wrote:
On 10/31/06, David Chadwick <d.w.chadwick@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@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 *****************************************************************
On 10/31/06, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Tom Scavo wrote:
On 10/31/06, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
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.
Without loss of generality, push and pull can be illustrated on one set of diagrams. Indeed, Figures 1 and 2 do just that.
This is actually quite a big difference in terms of usability, client complexity, privacy, etc.
But that seems mostly irrelevant to the primary purpose of the document.
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?
The entityID is the key to the SAML metadata file.
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?).
A complete metadata description of the AA will be found in metadata. Admittedly, the location endpoint of the AA is important, but it is not the only piece of metadata of interest.
We have included the latter in the existing SAML1.1 profile, as a URL, and can add it to the current spec as well.
What "existing SAML1.1 profile" are you referring to?
- the SAML Subject to use as a query subject
this is conceptually the authenticated name in the diagrams.
Is the "authenticated name" referred to in the diagram the DN from the certificate? If so, this *could* be used as the NameIdentifier in the query, but more generally, the issuer of the certificate may want to provide an alternate SAML Subject. In particular, the Format of this Subject may be something other than X509SubjectName.
It can be encoded as a SAML Subject if you wish. This is just detail.
No, not quite. If the Grid SP needs to query, it should first look in Subject Alt Name for a SAML Subject. If it doesn't find one, it should fall back on X509SubjectName.
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.
Exactly. The IdP entityID should go in the SIA extension.
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
Then why do we need a new profile? Can't we just use the "SAML 2.0 profile of XACML v2.0"? Tom
Hi Tom answers below. Old bits cut out. Tom Scavo wrote:
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?
The entityID is the key to the SAML metadata file.
At the conceptual level that we are talking about in this document there is no such thing as a SAML metadata file. That will come later when we map onto actual protocols. The concept of metadata or config data can be talked about however, and at this level all that is needed is a way of finding out how to contact the AA in order to get the user's credentials.
A complete metadata description of the AA will be found in metadata. Admittedly, the location endpoint of the AA is important, but it is not the only piece of metadata of interest.
Actually it is. If you do a complete analysis of the necessary interactions and data that is needed, all an AA needs to know is who the SP recipient is. All that an SP needs to know is how to contact the AA and optionally which attributes to ask for (by default it can ask for all of them that it is allowed to have).
We have included the latter in the existing SAML1.1 profile, as a URL, and can add it to the current spec as well.
What "existing SAML1.1 profile" are you referring to?
GFD.66 Use of SAML for OGSI Authorization the previous deliverable from the WG
- the SAML Subject to use as a query subject
this is conceptually the authenticated name in the diagrams.
Is the "authenticated name" referred to in the diagram the DN from the certificate?
The document does not go into such detail. In fact, in an X.509 PKC context all the subject alt names are authenticated names. If so, this *could* be used as the NameIdentifier in the
query, but more generally, the issuer of the certificate may want to provide an alternate SAML Subject. In particular, the Format of this Subject may be something other than X509SubjectName.
Again, the conceptual document is not really concerned with the formats of messages. This will come later in the protocol specs.
It can be encoded as a SAML Subject if you wish. This is just detail.
No, not quite. If the Grid SP needs to query, it should first look in Subject Alt Name for a SAML Subject. If it doesn't find one, it should fall back on X509SubjectName.
This is implementation details. In the general case, you cannot assume that an X.509 PKC will be used for authentication. I know that it always is in GT, but in other implementations Kerberos or un/pw might be acceptable.
Yes, this is what I already use in the draft profiles published earlier this year
Then why do we need a new profile? Can't we just use the "SAML 2.0 profile of XACML v2.0"?
I think you will find that some guidelines in addition to the above will be useful. Furthermore, if you want to combine protocols 1 and 3, or use pull mode instead of push mode, some more information will be needed. regards David
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@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 *****************************************************************
On 11/1/06, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Tom Scavo wrote:
A complete metadata description of the AA will be found in metadata. Admittedly, the location endpoint of the AA is important, but it is not the only piece of metadata of interest.
Actually it is. If you do a complete analysis of the necessary interactions and data that is needed, all an AA needs to know is who the SP recipient is. All that an SP needs to know is how to contact the AA and optionally which attributes to ask for (by default it can ask for all of them that it is allowed to have).
In the final analysis, yes, but the Grid SP (taken as a whole) needs to know 1) what is the preferred IdP of the user, and 2) what AA endpoint to query. Before the CVS can determine the latter, the PEP must supply the former. So I claim the unique identifier of the IdP (entityID) must travel from the user to the PEP to the CVS. Then and only then can the CVS determine the appropriate endpoint to query. Tom
Hi Tom Sorry but I have to disagree with you. Tom Scavo wrote:
In the final analysis, yes, but the Grid SP (taken as a whole) needs to know 1) what is the preferred IdP of the user,
Why does it need to know this? Surely the SP only needs to know which IdPs it trusts, but not which user is associated with which IdP. Only the user needs to know this and will choose it himself by WAYF or other means. and 2) what AA
endpoint to query. Before the CVS can determine the latter, the PEP must supply the former.
I agree with this (except that for small grids, the CVS can have a set of preconfigured AAs that it trusts. Actually even large grids can make do with this if there are a few globally trusted AAs. Consider Visa and Amex for instance. All the shopkeepers in the world only need to know these two or three AAs and no more for them to accept requests from the entire global population.) So I claim the unique identifier of the IdP
(entityID) must travel from the user to the PEP to the CVS.
I disagree. From the user to the PEP yes, since this will use it for authentication, but the CVS does not need to know this information. Then and
only then can the CVS determine the appropriate endpoint to query.
No, the message from the PEP can contain this information directly regards David
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@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 *****************************************************************
Somewhere in all of this I missed the time of this call. Can you kindly reconfirm? Alan On Oct 31, 2006, at 5:56 AM, David Chadwick wrote:
the next telecon is scheduled for Wed 8 November.
Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
Never mind, got the wrong Wednesday (sorry). Hopefully all details will be confirmed before the *real* next telecon, so we can feed the hungry maws of our respective calendars (scraps of paper we use as reminders, etc.). Apologies, Alan On Oct 31, 2006, at 5:56 AM, David Chadwick wrote:
the next telecon is scheduled for Wed 8 November.
Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
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.
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? 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. The proposal suggests 'tunneling' of SAML credentials inside a SAML attribute. You'd need to clearly specify the processing rules. 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? 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. Regards, Blair Dillaway
-----Original Message----- From: ogsa-authz-wg-bounces@ogf.org [mailto:ogsa-authz-wg-bounces@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@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
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@ogf.org [mailto:ogsa-authz-wg-bounces@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@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@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@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 *****************************************************************
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@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
participants (5)
-
Alan Sill -
Blair Dillaway -
David Chadwick -
Tom Scavo -
Yuri Demchenko