Re: [OGSA-AUTHZ] [ogsa-wg] [ogsa-authn-bof] Notes from Joint OGSA WG AuthN/AuthZ call
Hi Donal Donal K. Fellows wrote:
Blair Dillaway wrote:
I think we've all been disappointed by the level of participation in the AuthZ area. We really should consider whether continued work on the currently chartered documents is justified and what actions might lead to renewed interest.
I've been concerned about this for a while now and have spoken with some with other security professionals about this work. The general response was apathetic.
That's worrying, but not surprising. While I'm in a project with some very good security people, they're not interested in doing standards work *at all* at the moment. :-\
This is one of the problems. I believe that your project is more representative of the vast majority of projects, rather than my projects which always try to contribute towards the standardisation effort.
- Isn't the work already being done in OASIS on WS-Trust, XACML, etc. adequate
It would be nice if we could operate as profiles on those other specs.
but this is PRECISELY what we are doing in the OGSA Authz group. We are specifying profiles of XACML, SAML and WS-Trust. It is only by implementing common profiles that we can gain interoperability.
If we can't (and the only way we can tell is by thorough analysis of our use-cases, which are certainly fairly sophisticated when we start to think about multi-partner collaborations) then it is incumbent upon us to feed back this information to the OASIS guys.
If you dont want the OGF to produce profiles for grids, then we should indeed shut down the OGSA Authz group and join OASIS to specify our profiles there. Is this what you are suggesting?
- Standards in this area aren't a priority since most customers don't care about pluggability for these types of components.
My impression (as someone only intermittently involved) has been that it is horrendously difficult even to do the basic stages of interoperable AuthN, so the higher-level aspects (such as *all* of AuthZ!) have been largely ignored.
This is not my experience. We successfully specified the OGSA SAML Authz profile (GFD.66), implemented it in PERMIS, GT3 and 4, Primea (and more) and successfully performed interworking tests. It was not a painful experience at all. On the contrary it was very informative. This suggests to me that a valuable way forward would
be to put effort into trying to make these basic things work, which is very much the focus of the OGSA Express work. Maybe the advanced things are more academically interesting, but without the interoperable basic parts, it's suspiciously like a castle in the air.
Actually it is possible to do the two in parallel (Authn and Authz) since they are to some extent orthogonal. In fact you can use proprietary Authn procedures with standard Authz profiles quite successfully. So it is not a fixed sequential process. regards David (There are many
parallels with other parts of OGSA, such as in execution management where the really interesting things are in areas like reservations, but much needed to be worked on first so that the foundations could be built on which the fun stuff rests.)
Donal. -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-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 *****************************************************************
I appreciate Donal and David sharing their views on the current AuthZ work. Let me just say up front that I believe the approach of profiling other standards to address unique grid community needs is the right one. One can also identify grid needs that aren't being addressed in other standards groups. I would like to believe we're struggling with an issue of perceived importance, not approach. Questions I've been thinking about, and my take on the situation: - Why has participation dropped off despite historic interest? A couple of people have indicated their work commitments caused them to pull back. It also appears some people are prioritizing other standards work ahead of this effort. - Who are the key customers/implementers for these standards and why aren't they participating? As Frank noted the other day, other Globus security work has been prioritized ahead of standards. My own employer doesn't see these profiles as a current priority, which impacts my ability to engage in the WG. I suspect other potential implementers have similar views. The lack of response to David's request for requirements does make one question the demand from grid deployers. I previously mentioned the 'not a priority' reactions I got from some security folks not currently engaged in the OGF. So, it certainly seems like an uphill battle in convincing people this work is critical to undertake now. Putting together convincing arguments on the benefits, and socializing them with the grid community, would be a lot of work. I'm not even certain the WG could effectively engage on this given the current level of participation. Am I off-base on my perception of the situation? Are there other actions we should be considering? Regards, Blair Dillaway
Hi Blair Interestingly there is one aspect of authz that has a significant amount of user interest and that is merging attributes from Shibboleth and Grids to be used together for authz decision making. But this is currently not within the scope of the OGF OGSA Authz group's work plan. So what does this indicate? regards David Blair Dillaway wrote:
I appreciate Donal and David sharing their views on the current AuthZ work. Let me just say up front that I believe the approach of profiling other standards to address unique grid community needs is the right one. One can also identify grid needs that aren't being addressed in other standards groups. I would like to believe we're struggling with an issue of perceived importance, not approach.
Questions I've been thinking about, and my take on the situation: - Why has participation dropped off despite historic interest? A couple of people have indicated their work commitments caused them to pull back. It also appears some people are prioritizing other standards work ahead of this effort. - Who are the key customers/implementers for these standards and why aren't they participating? As Frank noted the other day, other Globus security work has been prioritized ahead of standards. My own employer doesn't see these profiles as a current priority, which impacts my ability to engage in the WG. I suspect other potential implementers have similar views. The lack of response to David's request for requirements does make one question the demand from grid deployers.
I previously mentioned the 'not a priority' reactions I got from some security folks not currently engaged in the OGF.
So, it certainly seems like an uphill battle in convincing people this work is critical to undertake now. Putting together convincing arguments on the benefits, and socializing them with the grid community, would be a lot of work. I'm not even certain the WG could effectively engage on this given the current level of participation.
Am I off-base on my perception of the situation? Are there other actions we should be considering?
Regards, Blair Dillaway
-- ***************************************************************** 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 don't remember any serious discussion of chartering work in this area, either within the AuthZ WG or elsewhere. So I can only surmise people haven't felt this area is adequately mature. The sessions Von hosted on Grid-Shib technology at OGF's last year certainly indicated a diverse set of approaches were being explored. Did you and Von discuss this in drafting the current charter? Do you believe things have evolved to the point where we could build critical mass around work in this area? (Of course, I'd love to hear from anyone who thinks the OGF should be doing work in this area.) Regards, Blair David Chadwick wrote:
Hi Blair
Interestingly there is one aspect of authz that has a significant amount of user interest and that is merging attributes from Shibboleth and Grids to be used together for authz decision making. But this is currently not within the scope of the OGF OGSA Authz group's work plan. So what does this indicate?
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
*****************************************************************
At a recent OGF AuthZ WG meeting (OGF19 or 20, I forget, but it's in the minutes), I mentioned the need for an X.509 Binding for SAML Assertions. We do this already in Globus CAS and GridShib, but it needs to be vetted and refined. I recently learned about a project in EU that is binding XACML to X.509, so perhaps we need a more general X.509 Binding for XML with separate profiles for SAML, XACML, and so forth. Once we have a standard X.509 Binding, we can profile attribute-based authz using both pushed and pulled SAML assertions. We've implemented a prototype along these lines and numerous issues have come up, which need vetting and further discussion. And finally there is the wholly unexplored territory of proxied SAML assertions, which most people believe are necessary to bridge campuses and grids, but there's absolutely no agreement how this should be done. Tom Scavo NCSA On 6/25/07, Blair Dillaway <blaird@microsoft.com> wrote:
I don't remember any serious discussion of chartering work in this area, either within the AuthZ WG or elsewhere. So I can only surmise people haven't felt this area is adequately mature. The sessions Von hosted on Grid-Shib technology at OGF's last year certainly indicated a diverse set of approaches were being explored.
Did you and Von discuss this in drafting the current charter? Do you believe things have evolved to the point where we could build critical mass around work in this area? (Of course, I'd love to hear from anyone who thinks the OGF should be doing work in this area.)
Regards, Blair
David Chadwick wrote:
Hi Blair
Interestingly there is one aspect of authz that has a significant amount of user interest and that is merging attributes from Shibboleth and Grids to be used together for authz decision making. But this is currently not within the scope of the OGF OGSA Authz group's work plan. So what does this indicate?
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 Tom Scavo wrote:
At a recent OGF AuthZ WG meeting (OGF19 or 20, I forget, but it's in the minutes), I mentioned the need for an X.509 Binding for SAML Assertions. We do this already in Globus CAS and GridShib, but it needs to be vetted and refined.
At OGF 20 we revisited this issue and agreed that we need one for SAML Attribute Assertions (but note, not for SAML Authz Decision Statements or Authn assertions, just for the attributes in order to be able to pull them).
I recently learned about a project in EU that is binding XACML to X.509, so perhaps we need a more general X.509 Binding for XML with separate profiles for SAML, XACML, and so forth.
Do you have the name of this project? Its not EGEE is it?
Once we have a standard X.509 Binding,
and the purpose of this would be to remove the use of SSL/TLS?? and to bind at the application layer rather than the transport layer? we can profile attribute-based
authz using both pushed and pulled SAML assertions. We've implemented a prototype along these lines and numerous issues have come up, which need vetting and further discussion.
When you say SAML assertions, this is too generic, since there are three types of assertions. Which ones do you mean?
And finally there is the wholly unexplored territory of proxied SAML assertions, which most people believe are necessary to bridge campuses and grids, but there's absolutely no agreement how this should be done.
You are correct. Proxying is another ball game. Which brings its own problems and conflicts (such as wanting authoritative assertions signed by their sources on the one hand, but going via a proxy and not knowing who the source is, on the other). What we need to do I believe is i) specify the protocols that are needed regardless of the bindings (so that the same XML constructs can be passed via a Java API, an SSL session, an X.509 binding or whatever). So far we have identified 3 of these, one for pulling attribute assertions, one for validating credentials and one for getting an authz decision. ii) specify a set of bindings that should be supported for the above. regards David
Tom Scavo NCSA
On 6/25/07, Blair Dillaway <blaird@microsoft.com> wrote:
I don't remember any serious discussion of chartering work in this area, either within the AuthZ WG or elsewhere. So I can only surmise people haven't felt this area is adequately mature. The sessions Von hosted on Grid-Shib technology at OGF's last year certainly indicated a diverse set of approaches were being explored.
Did you and Von discuss this in drafting the current charter? Do you believe things have evolved to the point where we could build critical mass around work in this area? (Of course, I'd love to hear from anyone who thinks the OGF should be doing work in this area.)
Regards, Blair
David Chadwick wrote:
Hi Blair
Interestingly there is one aspect of authz that has a significant amount of user interest and that is merging attributes from Shibboleth and Grids to be used together for authz decision making. But this is currently not within the scope of the OGF OGSA Authz group's work plan. So what does this indicate?
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 *****************************************************************
Hi David, I'll try to avoid diving into the details too soon. :-) Some general comments below. Tom On 6/26/07, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Tom Scavo wrote:
I recently learned about a project in EU that is binding XACML to X.509, so perhaps we need a more general X.509 Binding for XML with separate profiles for SAML, XACML, and so forth.
Do you have the name of this project? Its not EGEE is it?
http://www.rrzn.uni-hannover.de/ubp.html
Once we have a standard X.509 Binding,
and the purpose of this would be to remove the use of SSL/TLS?? and to bind at the application layer rather than the transport layer?
A SAML-laden certificate can be used for TLS client authentication or message-level security (via WSS X.509 Token Profile).
we can profile attribute-based
authz using both pushed and pulled SAML assertions. We've implemented a prototype along these lines and numerous issues have come up, which need vetting and further discussion.
When you say SAML assertions, this is too generic, since there are three types of assertions. Which ones do you mean?
There are an infinite number of assertions. I think you're referring to SAML statements. The current prototype transmits AuthenticationStatement and AttributeStatement. The plan is to combine the functionality of CAS and GridShib, at which time all three statement types come into play. Not sure why you're so concerned about statement types. An X.509 Binding for SAML Assertions does care much about the payload. (First we have to specify *how* to bind, then we can talk about *what* :) Tom
Hi Tom Tom Scavo wrote:
Not sure why you're so concerned about statement types. An X.509 Binding for SAML Assertions does care much about the payload. (First we have to specify *how* to bind, then we can talk about *what* :)
The reason being that the SAML Authz statement is now acknowledged to be deficient and we will formally deprecate it once the XACML request context replaces it 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
On 6/27/07, David Chadwick <d.w.chadwick@kent.ac.uk> wrote:
Tom Scavo wrote:
Not sure why you're so concerned about statement types. An X.509 Binding for SAML Assertions does care much about the payload. (First we have to specify *how* to bind, then we can talk about *what* :)
The reason being that the SAML Authz statement is now acknowledged to be deficient and we will formally deprecate it once the XACML request context replaces it
Again, I'll resist the urge to dive into a detailed discussion here, but I don't quite agree with this sentiment, so this could certainly become an agenda item that the AuthZ WG might consider. With regard to the concern Blair had about the need for an AuthN WG, I'll simply point out the overlap between AuthN and AuthZ insofar as the same security token might convey both types of security information. In our prototype, this is certainly the case, so having two separate WGs is less than ideal, at least with respect to the types of security tokens we are considering. Regards, Tom
Tom Scavo wrote:
With regard to the concern Blair had about the need for an AuthN WG ....
To be clear, I am actually supportive of work in the AuthN area. My concerns (as an AD) are about ensuring there is adequate support and active participation to justify chartering work on standards in this area. I remain concerned that the community lacks a shared vision on what standardized are critical to develop at this time. /Blair Dillaway
Blair Dillaway wrote:
I don't remember any serious discussion of chartering work in this area, either within the AuthZ WG or elsewhere. So I can only surmise people haven't felt this area is adequately mature. The sessions Von hosted on Grid-Shib technology at OGF's last year certainly indicated a diverse set of approaches were being explored.
Did you and Von discuss this in drafting the current charter?
Not directly. We thought this was running before we could walk. We wanted to get the base protocols defined first before starting on the more complex ones. Do you
believe things have evolved to the point where we could build critical mass around work in this area? (Of course, I'd love to hear from anyone who thinks the OGF should be doing work in this area.)
The only way to find this out is to suck it and see. this could be an item for the agenda of OGF21, or a polling of the maillist prior to that (preferred approach). regards David
Regards, Blair
David Chadwick wrote:
Hi Blair
Interestingly there is one aspect of authz that has a significant amount of user interest and that is merging attributes from Shibboleth and Grids to be used together for authz decision making. But this is currently not within the scope of the OGF OGSA Authz group's work plan. So what does this indicate?
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
*****************************************************************
-- ***************************************************************** 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 (3)
-
Blair Dillaway -
David Chadwick -
Tom Scavo