Use of IDList in Use of WS-TRUST and SAML to access a Credential Validation Service
Dear WG at our last meeting in Singapore, on a suggestion from Tom Scavo, we discussed changing from the GFD.66 SubjectAttributeReferenceAdvice element to the SAML IDList element and I made the edits to our profile. We have now been implementing this to see how it works in practice, and we have encountered the following problem, namely that IDList only lists attribute authorities and does not associate the attribute types that they issue with these attribute authorities. GFD.66 SubjectAttributeReferenceAdvice on the other hand does associate AAs with the attributes they issue. The meeting suggested that the implementation can pick up the attribute list from meta information of the AA, which indeed it can. However, this does not allow a user to specify which attributes he wants to use ie. provide the user with least privileges. Consider a VOMS server in which a user has multiple attributes. The meta information for the VOMS server will tell the CVS which attribute types are supported by the VOMS AA. But it will not help the CVS to decide which ones to ask for this user session, since the user is no able to tell the CVS which ones he wants. With SubjectAttributeReferenceAdvice the user was able to tell the CVS (indirectly via the PEP) which attributes he wished to be picked up from where for this session. With IDList the user is unable to tell the CVS. I am therefore proposing that we revert back to the SubjectAttributeReferenceAdvice element since it provides the user with the least privileges control that he needs. On the user's grid job request he adds the parameter "please pick up my attribute X from AA Y", which the PEP can then transfer to the CVS in the SubjectAttributeReferenceAdvice element. The CVS can perform the third party query mode request to the AA for the specified attribute (using the Use of SAML to retrieve Authorization Credentials profile), and if the user does have attribute X, this can be validated by the CVS and fed into the PDP. 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Hi David, There are two issues with the <SubjectAttributeReferenceAdvice> element (apart from the fact that it requires a proprietary schema): 1) it contains SAML V1.1 <AttributeDesignator> elements, which are gone in SAML V2.0; and 2) it contains URIs (as opposed to entityIDs) and therefore precludes the use of SAML metadata. I don't really understand your use case, so I can't suggest an alternative, but these two issues strongly argue against the <SubjectAttributeReferenceAdvice> element, I think. Tom On Fri, Oct 3, 2008 at 8:34 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Dear WG
at our last meeting in Singapore, on a suggestion from Tom Scavo, we discussed changing from the GFD.66 SubjectAttributeReferenceAdvice element to the SAML IDList element and I made the edits to our profile.
We have now been implementing this to see how it works in practice, and we have encountered the following problem, namely that IDList only lists attribute authorities and does not associate the attribute types that they issue with these attribute authorities. GFD.66 SubjectAttributeReferenceAdvice on the other hand does associate AAs with the attributes they issue.
The meeting suggested that the implementation can pick up the attribute list from meta information of the AA, which indeed it can. However, this does not allow a user to specify which attributes he wants to use ie. provide the user with least privileges.
Consider a VOMS server in which a user has multiple attributes. The meta information for the VOMS server will tell the CVS which attribute types are supported by the VOMS AA. But it will not help the CVS to decide which ones to ask for this user session, since the user is no able to tell the CVS which ones he wants. With SubjectAttributeReferenceAdvice the user was able to tell the CVS (indirectly via the PEP) which attributes he wished to be picked up from where for this session. With IDList the user is unable to tell the CVS.
I am therefore proposing that we revert back to the SubjectAttributeReferenceAdvice element since it provides the user with the least privileges control that he needs. On the user's grid job request he adds the parameter "please pick up my attribute X from AA Y", which the PEP can then transfer to the CVS in the SubjectAttributeReferenceAdvice element. The CVS can perform the third party query mode request to the AA for the specified attribute (using the Use of SAML to retrieve Authorization Credentials profile), and if the user does have attribute X, this can be validated by the CVS and fed into the PDP.
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://www.cs.kent.ac.uk/research/groups/iss/index.html 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 Tom I accept your comments about changing the syntax of <SubjectAttributeReferenceAdvice> to conform to SAMLv2 (it was originally written for SAML1.1 in GFD.66 and has not been updated yet). I will make these changes. Conceptually though, there is a requirement for the PEP to specify both the AA and the attribute(s) that is to be retrieved from it, since specifying the AA on its own is not at a sufficient level of granularity if the AA can assign multiple attributes (as in the VOMS case). We also plan to make use of this facility in the Shintau project when we aggregate attributes from multiple AAs regards David Tom Scavo wrote:
Hi David,
There are two issues with the <SubjectAttributeReferenceAdvice> element (apart from the fact that it requires a proprietary schema):
1) it contains SAML V1.1 <AttributeDesignator> elements, which are gone in SAML V2.0; and
2) it contains URIs (as opposed to entityIDs) and therefore precludes the use of SAML metadata.
I don't really understand your use case, so I can't suggest an alternative, but these two issues strongly argue against the <SubjectAttributeReferenceAdvice> element, I think.
Tom
On Fri, Oct 3, 2008 at 8:34 AM, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Dear WG
at our last meeting in Singapore, on a suggestion from Tom Scavo, we discussed changing from the GFD.66 SubjectAttributeReferenceAdvice element to the SAML IDList element and I made the edits to our profile.
We have now been implementing this to see how it works in practice, and we have encountered the following problem, namely that IDList only lists attribute authorities and does not associate the attribute types that they issue with these attribute authorities. GFD.66 SubjectAttributeReferenceAdvice on the other hand does associate AAs with the attributes they issue.
The meeting suggested that the implementation can pick up the attribute list from meta information of the AA, which indeed it can. However, this does not allow a user to specify which attributes he wants to use ie. provide the user with least privileges.
Consider a VOMS server in which a user has multiple attributes. The meta information for the VOMS server will tell the CVS which attribute types are supported by the VOMS AA. But it will not help the CVS to decide which ones to ask for this user session, since the user is no able to tell the CVS which ones he wants. With SubjectAttributeReferenceAdvice the user was able to tell the CVS (indirectly via the PEP) which attributes he wished to be picked up from where for this session. With IDList the user is unable to tell the CVS.
I am therefore proposing that we revert back to the SubjectAttributeReferenceAdvice element since it provides the user with the least privileges control that he needs. On the user's grid job request he adds the parameter "please pick up my attribute X from AA Y", which the PEP can then transfer to the CVS in the SubjectAttributeReferenceAdvice element. The CVS can perform the third party query mode request to the AA for the specified attribute (using the Use of SAML to retrieve Authorization Credentials profile), and if the user does have attribute X, this can be validated by the CVS and fed into the PDP.
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://www.cs.kent.ac.uk/research/groups/iss/index.html 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
participants (2)
-
David Chadwick -
Tom Scavo