A relatively simple way to implement an Extended Mode X.509 Attribute Query/Responder or Extended Mode X.509 Attribute Self-Query/Responder (both server-side components) is to deploy a Shibboleth Attribute Resolver in front of a VOMS attribute store. To do this, I would need to understand the VOMS schema (which I don't, but I assume I could look this up somewhere) but more importantly I'd need to know how to map a VOMS attribute to SAML. We've talked about this some on this list, but my question is: Is there a document that describes how to map a VOMS attribute to SAML? I suspect there is no such thing, so it seems we need a VOMS Attribute Profile for SAML, that is, a document that shows how to map VOMS attributes to SAML attributes. The structure of that profile would follow the attribute profiles in section 8 of the SAML V2.0 Profiles specification: http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf At first I thought there should be a section on VOMS attributes in the OGSA Attribute Exchange Profile, but the more I think about it, the more I think it should be separate. Thoughts? Tom Scavo NCSA
On Nov 27, 2007, at 11:32 AM, Tom Scavo wrote:
Is there a document that describes how to map a VOMS attribute to SAML?
I suspect there is no such thing, so it seems we need a VOMS Attribute Profile for SAML, that is, a document that shows how to map VOMS attributes to SAML attributes. The structure of that profile would follow the attribute profiles in section 8 of the SAML V2.0 Profiles specification:
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
The closest that exists is the document describing the VOMS AC format itself. If I searched correctly, that document is located at https://forge.gridforum.org/sf/go/doc13797 Alan Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics 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 : ====================================================================
Hi Tom we have already thought of this, and documented in the XACML profile how the various components of a VOMS FQAN are mapped into XACML attributes ready for passing to the PDP. The assumption is that the FQAN, which is simply a long string of various components, is passed by VOMS as a one long string based attribute with an attribute type of urn:oid: 1.3.6.1.4.1.8005.100.100.4 Have a look at the table in section 4.2.1 of the XACML profile for more details regards David Tom Scavo wrote:
A relatively simple way to implement an Extended Mode X.509 Attribute Query/Responder or Extended Mode X.509 Attribute Self-Query/Responder (both server-side components) is to deploy a Shibboleth Attribute Resolver in front of a VOMS attribute store. To do this, I would need to understand the VOMS schema (which I don't, but I assume I could look this up somewhere) but more importantly I'd need to know how to map a VOMS attribute to SAML. We've talked about this some on this list, but my question is: Is there a document that describes how to map a VOMS attribute to SAML?
I suspect there is no such thing, so it seems we need a VOMS Attribute Profile for SAML, that is, a document that shows how to map VOMS attributes to SAML attributes. The structure of that profile would follow the attribute profiles in section 8 of the SAML V2.0 Profiles specification:
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
At first I thought there should be a section on VOMS attributes in the OGSA Attribute Exchange Profile, but the more I think about it, the more I think it should be separate.
Thoughts?
Tom Scavo NCSA -- 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 *****************************************************************
Hi Tom
we have already thought of this, and documented in the XACML profile how the various components of a VOMS FQAN are mapped into XACML attributes But Tom needs SAML's. Anyway, since VOMS will be releasing SAML attributes, and they'll very likely be according to the XACML Attribute
On Wed, 2007-11-28 at 12:58 +0000, David Chadwick wrote: profile, we'll have a way to translate them to XACLM Attribute, that is according to the SAML Profile for XACML. That will sort auhtZ services out too. Valerio
Hi Valerio this probably means we need a short paragraph in the Attributes Exchange profile with a pointer to the XACML profile, along with some additional words of explanation. regards David Valerio Venturi wrote:
Hi Tom
we have already thought of this, and documented in the XACML profile how the various components of a VOMS FQAN are mapped into XACML attributes But Tom needs SAML's. Anyway, since VOMS will be releasing SAML attributes, and they'll very likely be according to the XACML Attribute
On Wed, 2007-11-28 at 12:58 +0000, David Chadwick wrote: profile, we'll have a way to translate them to XACLM Attribute, that is according to the SAML Profile for XACML. That will sort auhtZ services out too.
Valerio
-- ***************************************************************** 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 *****************************************************************
I haven't fully digested the material in section 4.2.1 of the XACML profile, but have you thought about separating this out into a separate profile? Converting VOMS attributes to SAML attributes is generally useful, not just for XACML. Thanks, Tom On 11/28/07, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Valerio
this probably means we need a short paragraph in the Attributes Exchange profile with a pointer to the XACML profile, along with some additional words of explanation.
regards
David
Valerio Venturi wrote:
Hi Tom
we have already thought of this, and documented in the XACML profile how the various components of a VOMS FQAN are mapped into XACML attributes But Tom needs SAML's. Anyway, since VOMS will be releasing SAML attributes, and they'll very likely be according to the XACML Attribute
On Wed, 2007-11-28 at 12:58 +0000, David Chadwick wrote: profile, we'll have a way to translate them to XACLM Attribute, that is according to the SAML Profile for XACML. That will sort auhtZ services out too.
Valerio
--
***************************************************************** 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 Tom this issue was discussed at length at OGF21 (see minutes). The conclusion was, if I remember correctly, that a separate document defining attribute, obligations and other parameters will be needed in the medium term, and it will take quite some time to produce it, since people will need operational experience in order to draw up the complete list. (In fact a live register might be better, similar to what IANA hold for various things.) But we need something now fast to get going. So the basic minimum will be in the profile docs which can be expected to be released soon, and then the other Standard Definitions doc or register can be produced incrementally over a longer period of time regards David Tom Scavo wrote:
I haven't fully digested the material in section 4.2.1 of the XACML profile, but have you thought about separating this out into a separate profile? Converting VOMS attributes to SAML attributes is generally useful, not just for XACML.
Thanks, Tom
On 11/28/07, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Valerio
this probably means we need a short paragraph in the Attributes Exchange profile with a pointer to the XACML profile, along with some additional words of explanation.
regards
David
Valerio Venturi wrote:
Hi Tom
we have already thought of this, and documented in the XACML profile how the various components of a VOMS FQAN are mapped into XACML attributes But Tom needs SAML's. Anyway, since VOMS will be releasing SAML attributes, and they'll very likely be according to the XACML Attribute
On Wed, 2007-11-28 at 12:58 +0000, David Chadwick wrote: profile, we'll have a way to translate them to XACLM Attribute, that is according to the SAML Profile for XACML. That will sort auhtZ services out too.
Valerio
--
***************************************************************** 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
*****************************************************************
-- ***************************************************************** 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 *****************************************************************
I was in favour of the profile separation too. In Seattle, I said it's something worth considering also for the PDP spec, since projects have ongoing efforts in defining for XACML ids. However, I understood, and understand David's concern on timing. Anyway, I don't know if it does really make sense to say that we put requirements inside the current spec now, because there's no time to prepare a spec on their own. Won't there be syncing problem beetwen the two? I suggest to see how and how fast the attribute profile proceeds before we decide. Valerio On Wed, 2007-11-28 at 19:14 +0000, David Chadwick wrote:
Hi Tom
this issue was discussed at length at OGF21 (see minutes). The conclusion was, if I remember correctly, that a separate document defining attribute, obligations and other parameters will be needed in the medium term, and it will take quite some time to produce it, since people will need operational experience in order to draw up the complete list. (In fact a live register might be better, similar to what IANA hold for various things.) But we need something now fast to get going. So the basic minimum will be in the profile docs which can be expected to be released soon, and then the other Standard Definitions doc or register can be produced incrementally over a longer period of time
regards
David
Tom Scavo wrote:
I haven't fully digested the material in section 4.2.1 of the XACML profile, but have you thought about separating this out into a separate profile? Converting VOMS attributes to SAML attributes is generally useful, not just for XACML.
Thanks, Tom
On 11/28/07, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Hi Valerio
this probably means we need a short paragraph in the Attributes Exchange profile with a pointer to the XACML profile, along with some additional words of explanation.
regards
David
Valerio Venturi wrote:
Hi Tom
we have already thought of this, and documented in the XACML profile how the various components of a VOMS FQAN are mapped into XACML attributes But Tom needs SAML's. Anyway, since VOMS will be releasing SAML attributes, and they'll very likely be according to the XACML Attribute
On Wed, 2007-11-28 at 12:58 +0000, David Chadwick wrote: profile, we'll have a way to translate them to XACLM Attribute, that is according to the SAML Profile for XACML. That will sort auhtZ services out too.
Valerio
--
***************************************************************** 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
*****************************************************************
On Tue, 2007-11-27 at 12:32 -0500, Tom Scavo wrote:
A relatively simple way to implement an Extended Mode X.509 Attribute Query/Responder or Extended Mode X.509 Attribute Self-Query/Responder (both server-side components) is to deploy a Shibboleth Attribute Resolver in front of a VOMS attribute store. To do this, I would need to understand the VOMS schema (which I don't, but I assume I could look this up somewhere) but more importantly I'd need to know how to map a VOMS attribute to SAML. We've talked about this some on this list, but my question is: Is there a document that describes how to map a VOMS attribute to SAML?
I suspect there is no such thing, so it seems we need a VOMS Attribute Profile for SAML, that is, a document that shows how to map VOMS There is no such thing yet, but there's some work in progress. Also Krzysztof Benedyczak is working on a service with a semantic similar to VOMS, a VO service, so we have been trying to unify the efforts and have a common VO SAML 2.0 Attribute Profile. Your help and expertise would be very much appreciate in finalizing it. I think that we may circulate the document here and start a discussion. Krzysztof, is that ok with you?
attributes to SAML attributes. The structure of that profile would follow the attribute profiles in section 8 of the SAML V2.0 Profiles specification:
http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
At first I thought there should be a section on VOMS attributes in the OGSA Attribute Exchange Profile, but the more I think about it, the more I think it should be separate. I agree they should be separate.
Valerio
Hi All, Valerio Venturi wrote:
On Tue, 2007-11-27 at 12:32 -0500, Tom Scavo wrote:
A relatively simple way to implement an Extended Mode X.509 Attribute Query/Responder or Extended Mode X.509 Attribute Self-Query/Responder (both server-side components) is to deploy a Shibboleth Attribute Resolver in front of a VOMS attribute store. To do this, I would need to understand the VOMS schema (which I don't, but I assume I could look this up somewhere) but more importantly I'd need to know how to map a VOMS attribute to SAML. We've talked about this some on this list, but my question is: Is there a document that describes how to map a VOMS attribute to SAML?
I suspect there is no such thing, so it seems we need a VOMS Attribute Profile for SAML, that is, a document that shows how to map VOMS There is no such thing yet, but there's some work in progress. Also Krzysztof Benedyczak is working on a service with a semantic similar to VOMS, a VO service, so we have been trying to unify the efforts and have a common VO SAML 2.0 Attribute Profile. Your help and expertise would be very much appreciate in finalizing it. I think that we may circulate the document here and start a discussion. Krzysztof, is that ok with you? Yes, of course.
Best regards, Krzysztof
participants (5)
-
Alan Sill -
David Chadwick -
Krzysztof Benedyczak -
Tom Scavo -
Valerio Venturi