Comments for Document: Use of XACML Request Context to Obtain an Authorisation Decision
Comments:
| Author(s): | D. Chadwick, L. Su, R. Laborde |
| Type: | P-REC |
| Area: | Security |
| Group: | OGSA-Authz-WG |
| Public Comment End: | 13 Aug, 2008 |
Comments:
Posted by: lajoie 2008-08-07 03:38:09EGEE Comments
The EGEE Collaboration has the following comments on 'Use of XACML Request Context to Obtain an Authorisation Decision". These comments are based on the belief that the purpose of this document is to specify one or more interoperable messages to be used between various parties for the purpose of reaching an authorization decision.
Technical Comments
- This document does not describe any transport binding aspects for the message. As such, two systems attempting to communicate could use vastly different transport mechanisms and thus be unable to interoperate.
- This document does not provide any message profiling. For example, one issue is that there are multiple versions of XACML. The latest profile from OASIS, that describes the use of the SAML protocol for carrying XACML authorization decision request/responses, allows for any XACML version to be used. Obviously different components using different versions will not be interoperable. Additionally, there is no mention of the XACML policy query request message and what message constraints would be required such that implementations would be likely to interoperate.
- This document does no describe any digital signature constraints or usage semantics. This presents quite a few interoperability problems. As an example, which canonicalization or transformation methods are required/supported, what keying material is supported and how it is represented, etc.
- This document conflates the validation of credentials (authorization) with the rendering of an authorization decision. XACML is based on the idea that a PEP is a trusted component and that the information it delivers should be treated as trusted data. The mechanism by which the PEP determines the validity and trustworthiness is out of scope. Additionally, we would recommend against deploying, or using, this system because it promotes the forwarding of credentials to a third party, of which the credential issuer is unaware. While this occurs within the grid regularly we recognize that it is a severe security risk.
- This document does not profile any status messages. This is especially problematic in the case of error messages. Without a profiling of such messages it is very likely that different components would use different status messages, for the same or similar error cases, than other components. This will make it difficult, if not impossible, for a requester to rely on this data.
Non-Technical Comments
- This document does not represent the consensus of the community. The SOAP Profile for XACML-SAML[1] is being used by the EGEE and OSG grid deployments within the applications LCAS/LCMAPS, CREAM, SCAS, GUMS, GT AuthZ Framework, gPlazma and PRIMA. This document was provided to the OGSA-AuthZ working group and, as David Chadwick notes in his email to the OGSA-AuthZ working group mailing list on March 31st, this OGSA-AuthZ document was known to be different from the work of the community at the time it went for comment.
It is therefore our proposal that, based on the OGSA-AuthZ document and the SOAP Profile [2], a subsequent concerted effort be established to reach broader community consensus on a new harmonized profile to be used in all applications.
[1] http://switch.ch/grid/support/documents/xacmlsaml.pdf
Technical Comments
- This document does not describe any transport binding aspects for the message. As such, two systems attempting to communicate could use vastly different transport mechanisms and thus be unable to interoperate.
- This document does not provide any message profiling. For example, one issue is that there are multiple versions of XACML. The latest profile from OASIS, that describes the use of the SAML protocol for carrying XACML authorization decision request/responses, allows for any XACML version to be used. Obviously different components using different versions will not be interoperable. Additionally, there is no mention of the XACML policy query request message and what message constraints would be required such that implementations would be likely to interoperate.
- This document does no describe any digital signature constraints or usage semantics. This presents quite a few interoperability problems. As an example, which canonicalization or transformation methods are required/supported, what keying material is supported and how it is represented, etc.
- This document conflates the validation of credentials (authorization) with the rendering of an authorization decision. XACML is based on the idea that a PEP is a trusted component and that the information it delivers should be treated as trusted data. The mechanism by which the PEP determines the validity and trustworthiness is out of scope. Additionally, we would recommend against deploying, or using, this system because it promotes the forwarding of credentials to a third party, of which the credential issuer is unaware. While this occurs within the grid regularly we recognize that it is a severe security risk.
- This document does not profile any status messages. This is especially problematic in the case of error messages. Without a profiling of such messages it is very likely that different components would use different status messages, for the same or similar error cases, than other components. This will make it difficult, if not impossible, for a requester to rely on this data.
Non-Technical Comments
- This document does not represent the consensus of the community. The SOAP Profile for XACML-SAML[1] is being used by the EGEE and OSG grid deployments within the applications LCAS/LCMAPS, CREAM, SCAS, GUMS, GT AuthZ Framework, gPlazma and PRIMA. This document was provided to the OGSA-AuthZ working group and, as David Chadwick notes in his email to the OGSA-AuthZ working group mailing list on March 31st, this OGSA-AuthZ document was known to be different from the work of the community at the time it went for comment.
It is therefore our proposal that, based on the OGSA-AuthZ document and the SOAP Profile [2], a subsequent concerted effort be established to reach broader community consensus on a new harmonized profile to be used in all applications.
[1] http://switch.ch/grid/support/documents/xacmlsaml.pdf
Posted by: dwchadwick 2009-07-22 04:13:04test
Posted by: dwchadwick 2009-07-22 04:36:47Response to Public Comments on Use of XACML Request Context to Obtain an Authorisation Decision
In this document the comments are in normal text and the responses are prefixed and terminated with ***.
The EGEE Collaboration has the following comments on 'Use of XACML Request Context to Obtain an Authorisation Decision". These comments are based on the belief that the purpose of this document is to specify one or more interoperable messages to be used between various parties for the purpose of reaching an authorization decision.
*** That is correct. ***
Technical Comments
- This document does not describe any transport binding aspects for the message. As such, two systems attempting to communicate could use vastly different transport mechanisms and thus be unable to interoperate.
*** A new section 7 has been added entitled “Mapping to Lower Layer Protocols� in order to address this issue.***
- This document does not provide any message profiling. For example, one issue is that there are multiple versions of XACML. The latest profile from OASIS, that describes the use of the SAML protocol for carrying XACML authorization decision request/responses, allows for any XACML version to be used. Obviously different components using different versions will not be interoperable. Additionally, there is no mention of the XACML policy query request message and what message constraints would be required such that implementations would be likely to interoperate.
*** We have made it clear now that we are referring to XACMLv2 throughout by explicitly adding the version number. ***
- This document does no describe any digital signature constraints or usage semantics. This presents quite a few interoperability problems. As an example, which canonicalization or transformation methods are required/supported, what keying material is supported and how it is represented, etc.
*** The profile does not support XML signatures. We have tightened up section 8, “Security Considerations�, to make it clear that SSL/TLS must be used to provide mutual authentication rather than XML signed messages.***
- This document conflates the validation of credentials (authorization) with the rendering of an authorization decision. XACML is based on the idea that a PEP is a trusted component and that the information it delivers should be treated as trusted data. The mechanism by which the PEP determines the validity and trustworthiness is out of scope [of the XACML specification – ed].
*** This is precisely why we have added the (optional) validation of credentials to the OGF specification, since XACML is deficient in this area. Whilst the OGF profile supports the passing of trusted attributes as anticipated in the XACML specification, it also supports the passing of digitally signed credentials which in reality is what the PEP receives. The OGF profiles allow the PEP to either validate the credentials itself, or to pass them to the context handler of the PDP for it to validate them before calling the PDP with the trusted attributes. This allows resource sites the flexibility to configure their credential validation service in the most appropriate manner for them.***
Additionally, we would recommend against deploying, or using, this system because it promotes the forwarding of credentials to a third party, of which the credential issuer is unaware. While this occurs within the grid regularly we recognize that it is a severe security risk.
*** We do not propose the passing of credentials to any third party. The model we use does not assume that any third party is involved. On the contrary it is expected that a site’s authorisation service comprises several functional components, all of which are under the same management, and the OGF profiles specify how these functional components can communicate with each other. There is no third party involved in this dialogue as the same administration manages all the functional components (which are instantiated as web services to provide functional services to each other).***
- This document does not profile any status messages.
*** This is correct. It does not profile any subject attributes or obligations either, because as you may recall, it was EGEE who asked for these to be removed from a previous version of the profile. In order to conform to your wishes we placed these in non-normative annexes. The Authz working group decided that profiling these types of information should be performed in a separate working group document which is yet to be defined. So if you have a contribution to make it would be most welcome.***
This is especially problematic in the case of error messages. Without a profiling of such messages it is very likely that different components would use different status messages, for the same or similar error cases, than other components. This will make it difficult, if not impossible, for a requester to rely on this data.
*** In the same way that the non-profiling of attributes and obligations will cause interworking problems as well, e.g. if different semantics are attached to the same attributes, or systems support different subsets of attributes and obligations.***
Non-Technical Comments
- This document does not represent the consensus of the community.
*** It represents the consensus of the OGF community and of everyone who has participated in the OGSA-Authz WG over many years. If you would like the OGF profiles to conform to your viewpoints then might I suggest that you participate in the working group meetings and its mailing list.***
The SOAP Profile for XACML-SAML[1] is being used by the EGEE and OSG grid deployments within the applications LCAS/LCMAPS, CREAM, SCAS, GUMS, GT AuthZ Framework, gPlazma and PRIMA. This document was provided to the OGSA-AuthZ working group and, as David Chadwick notes in his email to the OGSA-AuthZ working group mailing list on March 31st, this OGSA-AuthZ document was known to be different from the work of the community at the time it went for comment.
It is therefore our proposal that, based on the OGSA-AuthZ document and the SOAP Profile [2], (I assume you mean [1] – ed.) a subsequent concerted effort be established to reach broader community consensus on a new harmonized profile to be used in all applications.
[1] http://switch.ch/grid/support/documents/xacmlsaml.pdf
*** The OGF as a matter of policy is very happy for anyone to collaborate with it and its meetings are open to anyone to attend. If by concerted effort you mean that you will now start to participate in OGF standardisation activities then this will be greatly welcomed. If on the other hand you mean that the OGF should stop its work in this area and the people should stop attending OGF and should start to attend another forum along with yourselves, then I am not sure that the OGF would welcome this approach.***
David Chadwick
21 July 2009
The EGEE Collaboration has the following comments on 'Use of XACML Request Context to Obtain an Authorisation Decision". These comments are based on the belief that the purpose of this document is to specify one or more interoperable messages to be used between various parties for the purpose of reaching an authorization decision.
*** That is correct. ***
Technical Comments
- This document does not describe any transport binding aspects for the message. As such, two systems attempting to communicate could use vastly different transport mechanisms and thus be unable to interoperate.
*** A new section 7 has been added entitled “Mapping to Lower Layer Protocols� in order to address this issue.***
- This document does not provide any message profiling. For example, one issue is that there are multiple versions of XACML. The latest profile from OASIS, that describes the use of the SAML protocol for carrying XACML authorization decision request/responses, allows for any XACML version to be used. Obviously different components using different versions will not be interoperable. Additionally, there is no mention of the XACML policy query request message and what message constraints would be required such that implementations would be likely to interoperate.
*** We have made it clear now that we are referring to XACMLv2 throughout by explicitly adding the version number. ***
- This document does no describe any digital signature constraints or usage semantics. This presents quite a few interoperability problems. As an example, which canonicalization or transformation methods are required/supported, what keying material is supported and how it is represented, etc.
*** The profile does not support XML signatures. We have tightened up section 8, “Security Considerations�, to make it clear that SSL/TLS must be used to provide mutual authentication rather than XML signed messages.***
- This document conflates the validation of credentials (authorization) with the rendering of an authorization decision. XACML is based on the idea that a PEP is a trusted component and that the information it delivers should be treated as trusted data. The mechanism by which the PEP determines the validity and trustworthiness is out of scope [of the XACML specification – ed].
*** This is precisely why we have added the (optional) validation of credentials to the OGF specification, since XACML is deficient in this area. Whilst the OGF profile supports the passing of trusted attributes as anticipated in the XACML specification, it also supports the passing of digitally signed credentials which in reality is what the PEP receives. The OGF profiles allow the PEP to either validate the credentials itself, or to pass them to the context handler of the PDP for it to validate them before calling the PDP with the trusted attributes. This allows resource sites the flexibility to configure their credential validation service in the most appropriate manner for them.***
Additionally, we would recommend against deploying, or using, this system because it promotes the forwarding of credentials to a third party, of which the credential issuer is unaware. While this occurs within the grid regularly we recognize that it is a severe security risk.
*** We do not propose the passing of credentials to any third party. The model we use does not assume that any third party is involved. On the contrary it is expected that a site’s authorisation service comprises several functional components, all of which are under the same management, and the OGF profiles specify how these functional components can communicate with each other. There is no third party involved in this dialogue as the same administration manages all the functional components (which are instantiated as web services to provide functional services to each other).***
- This document does not profile any status messages.
*** This is correct. It does not profile any subject attributes or obligations either, because as you may recall, it was EGEE who asked for these to be removed from a previous version of the profile. In order to conform to your wishes we placed these in non-normative annexes. The Authz working group decided that profiling these types of information should be performed in a separate working group document which is yet to be defined. So if you have a contribution to make it would be most welcome.***
This is especially problematic in the case of error messages. Without a profiling of such messages it is very likely that different components would use different status messages, for the same or similar error cases, than other components. This will make it difficult, if not impossible, for a requester to rely on this data.
*** In the same way that the non-profiling of attributes and obligations will cause interworking problems as well, e.g. if different semantics are attached to the same attributes, or systems support different subsets of attributes and obligations.***
Non-Technical Comments
- This document does not represent the consensus of the community.
*** It represents the consensus of the OGF community and of everyone who has participated in the OGSA-Authz WG over many years. If you would like the OGF profiles to conform to your viewpoints then might I suggest that you participate in the working group meetings and its mailing list.***
The SOAP Profile for XACML-SAML[1] is being used by the EGEE and OSG grid deployments within the applications LCAS/LCMAPS, CREAM, SCAS, GUMS, GT AuthZ Framework, gPlazma and PRIMA. This document was provided to the OGSA-AuthZ working group and, as David Chadwick notes in his email to the OGSA-AuthZ working group mailing list on March 31st, this OGSA-AuthZ document was known to be different from the work of the community at the time it went for comment.
It is therefore our proposal that, based on the OGSA-AuthZ document and the SOAP Profile [2], (I assume you mean [1] – ed.) a subsequent concerted effort be established to reach broader community consensus on a new harmonized profile to be used in all applications.
[1] http://switch.ch/grid/support/documents/xacmlsaml.pdf
*** The OGF as a matter of policy is very happy for anyone to collaborate with it and its meetings are open to anyone to attend. If by concerted effort you mean that you will now start to participate in OGF standardisation activities then this will be greatly welcomed. If on the other hand you mean that the OGF should stop its work in this area and the people should stop attending OGF and should start to attend another forum along with yourselves, then I am not sure that the OGF would welcome this approach.***
David Chadwick
21 July 2009
Posted by: chenxin111 2012-06-04 02:07:15New Air Jordans
Air Jordan shoes Jordan have not only dominated
Air Jordan 2011 the sports and particularly 2011 air jordan the Basketball, but they also have been incorporated into the music world; for Retro Jordans instance it's not anything new to see pop music celebrities adorning The New Air Jordans the shoe. Hollywood celebrities too have not been left out.For example Nike
and Jordan Brand Air Jordan 2011 Air Jordan shoes specifically designed for the hip hop.
Air Jordan 2011 the sports and particularly 2011 air jordan the Basketball, but they also have been incorporated into the music world; for Retro Jordans instance it's not anything new to see pop music celebrities adorning The New Air Jordans the shoe. Hollywood celebrities too have not been left out.For example Nike
and Jordan Brand Air Jordan 2011 Air Jordan shoes specifically designed for the hip hop.
login
RSS
Contact Webmaster
OGFSM, Open Grid ForumSM, Grid ForumSM,
and the OGF Logo are trademarks of OGF