OGSA AuthN/AuthZ joint call Chris David Mark Morgan Andrew Grimshaw FrankSiebenlist Jack Hiro Kishimoto Alan Sill Andreas Savva Stephen Agenda items: OGSA-AuthZ update (David Chadwick) OGSA-AuthN update (Alan Sill) David summarized the current state of the OGSA-AuthZ work. No progress or changes have taken place since OGF-20 on the document set from the AuthZ work groupl Jargon for below: PDP = policy decision point PEP = policy enforcement point PIP = policy information point GFD-66 and 67 (65?) status GFD-66 was intended to describe the relation between PDPs and PEPs Previous version of GFD-66 based on SAML 1.1 was implemented by several groups and found to be insufficient. An architecture document was written by David and others to propose 3 protocols: one for pull of credentials from an IdP or AA according to any of several protocols profiled by OASIS and others, an XACML protocol, and a credential validation service profile defined according to WS-trust. Alan requested that David get a document number for this architecture document and David agreed to move this along the path to formalization. It would be good to publish this as an informational document, with the 3 protocols pulled into separate documents. Frank said that progress at Argonne on this has been slowed by work being done for GT4.2 - all security programmers have been pulled onto that work and have not had sufficient time available for standards work. GFD-66 had value but does not extend to sufficiently realistic complex real-world use case requirements, for example validating signed credentials, interactions with PIPs, etc. For requirements gathering, David put up a wiki but got very few submissions. Stephen points out that people see a need for security but do not see the relevance of the work done here, and socialization of the work being done here is not sufficiently seen as connected to real-world needs. Alan agreed that this is an important component of the work and is exactly what Duane, mark and Andrew have been trying to do in the requirements-gathering work they have been doing for the short-term AuthN documentation work they have been done. Frank did not understand the disconnect, as the XACML work for example has been driven by strong communication between developers and community segments that have requested this work. Andrew says that the exercise of writing a use-case document has proven itself even in circumstances in which the use cases are thought to be well- known. Stephen and Alan felt this to be true even though writing such documents can be a chore. People are often stuck on simple cases when the community doing work on standards is often focused on more advanced use cases. Andrew pointed out that documenting even the simple use cases is of value and must be written down to get rid of this barrier for users; some of the work being done for the HPC profile was driven by this need. Last week David sent out a document written from the point of view of Authorization meant to match some of the current "simple AuthN" work. Mark more or less simultaneously requested such a document. Discussion followed as to whether AuthZ can be folded into the current security profile "express" documentation work being done, or instead whether another document to address "express authZ" should be written. Andrew prefers simple short documents over grand scheme documents at this stage. Another document in this series entitled "OGSA Security Profile 2.0 - Authorization" would be helpful. David agreed to look at this and will go through the current set from this perspective. Moving on to authentication topics Alan is ready now to restart work on the OGSA-AuthN topics. Motivations here include examining the technical requirements of implementations and ensuring that the documentation and standards set offered by OGSA is sufficiently flexible and well-specified to allow interoperable implementations based on different technologies. As an example, Alan asks why Ws- Security is so SOAP-oriented, when grid implementations can be written based on the same WSDL and XML that could provide code using different RPC methods? Other motivations include ensuring that Shibboleth grid integration can be done on a well-defined standards basis within OGSA, and while this is largely an AuthZ question, we need to make sure that the OGSA-AuthN pieces and basis for this work are sufficiently documented, understood and specified. A documentation call series will be started sometime in July to get this work going. Simultaneously, work should be continued to complete the "express profile" documentation series. Hiro asked about the timing of the next joint call. David has Sep. 13 down as the next joint call. Hiro offered time at the Sunnyvale F2F Aug. 13-16. 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 : ====================================================================
Thanks Alan this is a very good set of minutes David Alan Sill wrote:
OGSA AuthN/AuthZ joint call
Chris David Mark Morgan Andrew Grimshaw FrankSiebenlist Jack Hiro Kishimoto Alan Sill Andreas Savva Stephen
Agenda items:
OGSA-AuthZ update (David Chadwick) OGSA-AuthN update (Alan Sill)
David summarized the current state of the OGSA-AuthZ work. No progress or changes have taken place since OGF-20 on the document set from the AuthZ work groupl
Jargon for below: PDP = policy decision point PEP = policy enforcement point PIP = policy information point
GFD-66 and 67 (65?) status GFD-66 was intended to describe the relation between PDPs and PEPs Previous version of GFD-66 based on SAML 1.1 was implemented by several groups and found to be insufficient.
An architecture document was written by David and others to propose 3 protocols: one for pull of credentials from an IdP or AA according to any of several protocols profiled by OASIS and others, an XACML protocol, and a credential validation service profile defined according to WS-trust. Alan requested that David get a document number for this architecture document and David agreed to move this along the path to formalization. It would be good to publish this as an informational document, with the 3 protocols pulled into separate documents.
Frank said that progress at Argonne on this has been slowed by work being done for GT4.2 - all security programmers have been pulled onto that work and have not had sufficient time available for standards work.
GFD-66 had value but does not extend to sufficiently realistic complex real-world use case requirements, for example validating signed credentials, interactions with PIPs, etc.
For requirements gathering, David put up a wiki but got very few submissions. Stephen points out that people see a need for security but do not see the relevance of the work done here, and socialization of the work being done here is not sufficiently seen as connected to real-world needs. Alan agreed that this is an important component of the work and is exactly what Duane, mark and Andrew have been trying to do in the requirements-gathering work they have been doing for the short-term AuthN documentation work they have been done.
Frank did not understand the disconnect, as the XACML work for example has been driven by strong communication between developers and community segments that have requested this work. Andrew says that the exercise of writing a use-case document has proven itself even in circumstances in which the use cases are thought to be well- known. Stephen and Alan felt this to be true even though writing such documents can be a chore.
People are often stuck on simple cases when the community doing work on standards is often focused on more advanced use cases. Andrew pointed out that documenting even the simple use cases is of value and must be written down to get rid of this barrier for users; some of the work being done for the HPC profile was driven by this need.
Last week David sent out a document written from the point of view of Authorization meant to match some of the current "simple AuthN" work. Mark more or less simultaneously requested such a document. Discussion followed as to whether AuthZ can be folded into the current security profile "express" documentation work being done, or instead whether another document to address "express authZ" should be written. Andrew prefers simple short documents over grand scheme documents at this stage. Another document in this series entitled "OGSA Security Profile 2.0 - Authorization" would be helpful. David agreed to look at this and will go through the current set from this perspective.
Moving on to authentication topics Alan is ready now to restart work on the OGSA-AuthN topics. Motivations here include examining the technical requirements of implementations and ensuring that the documentation and standards set offered by OGSA is sufficiently flexible and well-specified to allow interoperable implementations based on different technologies. As an example, Alan asks why Ws- Security is so SOAP-oriented, when grid implementations can be written based on the same WSDL and XML that could provide code using different RPC methods? Other motivations include ensuring that Shibboleth grid integration can be done on a well-defined standards basis within OGSA, and while this is largely an AuthZ question, we need to make sure that the OGSA-AuthN pieces and basis for this work are sufficiently documented, understood and specified. A documentation call series will be started sometime in July to get this work going.
Simultaneously, work should be continued to complete the "express profile" documentation series.
Hiro asked about the timing of the next joint call. David has Sep. 13 down as the next joint call. Hiro offered time at the Sunnyvale F2F Aug. 13-16.
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 : ====================================================================
-- 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 *****************************************************************
Hi All: Excellent notes Alan. My apologies for missing this discussion, but I had other obligations. I have several comments on the issues discussed (only excerpts included for brevity).
Andrew says that the exercise of writing a use-case document has proven itself even in circumstances in which the use cases are thought to be well- known.
I fully concur. Getting use-cases documented and socialized with the expected contributors/adopters is a critical step. It establishes scope, helps convey the value, and identifies the expected application of the standard.
Last week David sent out a document written from the point of view of Authorization meant to match some of the current "simple AuthN" work. ... Discussion followed as to whether AuthZ can be folded into the current security profile "express" documentation work being done, or instead whether another document to address "express authZ" should be written.
Adding such a document to the work could be reasonable. It does seem the 'express' work would benefit from writing down a defined scope for the current work to avoid incremental scope expansion.
Alan asks why Ws- Security is so SOAP-oriented, when grid implementations can be written based on the same WSDL and XML that could provide code using different RPC methods?
The question to ask here is whether grids should move toward relying on web services as the basis for interoperability? There is certainly a strong push in this direction, which I support. Web services are based on the use of SOAP messaging. WS-Security's official name is "Web Services Security: SOAP Message Security". Hence, the focus on SOAP messaging. If one wishes to use other protocols, such as RPC, there are other security standards which are appropriate.
Moving on to authentication topics Alan is ready now to restart work on the OGSA-AuthN topics.... Simultaneously, work should be continued to complete the "express profile" documentation series.
While there are certainly interesting AuthN topics to discuss which go beyond the identified 'express' work, I am very concerned about having two AuthN groups working in parallel. It has been difficult to achieve critical mass on OGF security standard's work and I fear we'll end-up with inadequate engagement on both efforts. I suggest we look seriously at combining these efforts. Is there a scope/sequencing of work which makes sense where the 'express' profiles are the first set of deliverables for a more broadly chartered group? I don't personally care if such a group is officially part of OGSA or the Security area. I raised this issue at OGF20, but haven't heard from anyone regarding their opinion on having one versus two efforts. On a separate thread, David Chadwick wrote:
Concerning the Autthz agenda item, there is no progress to report since oGF20. One thing we might like to consider is how do we engage the community more in contributing to this work, or do we just throw in our hats and say that no-one is really interested in pushing the authz work forward anymore and Alan wrote: For requirements gathering, David put up a wiki but got very few submissions. Stephen points out that people see a need for security but do not see the relevance of the work done here, and socialization of the work being done here is not sufficiently seen as connected to real-world needs.
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. Major comments were along the lines of: - Isn't the work already being done in OASIS on WS-Trust, XACML, etc. adequate - Standards in this area aren't a priority since most customers don't care about pluggability for these types of components. I have found it difficult to present a compelling counter to such arguments.
Hiro asked about the timing of the next joint call. David has Sep. 13 down as the next joint call. Hiro offered time at the Sunnyvale F2F Aug. 13-16.
FYI, I will not be able to attend the F2F. Regards, Blair Dillaway
Blair Dillaway wrote:
...
On a separate thread, David Chadwick wrote:
Concerning the Autthz agenda item, there is no progress to report since oGF20. One thing we might like to consider is how do we engage the community more in contributing to this work, or do we just throw in our hats and say that no-one is really interested in pushing the authz work forward anymore and Alan wrote: For requirements gathering, David put up a wiki but got very few submissions. Stephen points out that people see a need for security but do not see the relevance of the work done here, and socialization of the work being done here is not sufficiently seen as connected to real-world needs.
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. Major comments were along the lines of: - Isn't the work already being done in OASIS on WS-Trust, XACML, etc. adequate - Standards in this area aren't a priority since most customers don't care about pluggability for these types of components. I have found it difficult to present a compelling counter to such arguments.
Excellent points. If the security area director cannot find any relevant interest within the grid community for the authz work after such thorough review, we should definitely pull the plug. Regards, Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Frank Siebenlist 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. Major comments were along the lines of: - Isn't the work already being done in OASIS on WS-Trust, XACML, etc. adequate - Standards in this area aren't a priority since most customers don't care about pluggability for these types of components. I have found it difficult to present a compelling counter to such arguments.
Excellent points.
If the security area director cannot find any relevant interest within the grid community for the authz work after such thorough review, we should definitely pull the plug.
A 'thorough review' isn't how I'd characterize this. My comments were based on conversations with several professionals who work on related security products but are not active in the OGF. Their views represent important data points, though may not be universal. I encourage all interested parties to share their views on this. Thanks, Blair Dillaway
On Jun 21, 2007, at 1:40 PM, Blair Dillaway wrote:
Excellent notes Alan.
On Jun 21, 2007, at 11:21 AM, David Chadwick wrote:
this is a very good set of minutes
Thanks. It was a broad-ranging discussion so credit goes to Andrew, David, Frank, Mark, Stephen and Hiro for pulling it together and contributing to it.
The question to ask here is whether grids should move toward relying on web services as the basis for interoperability? There is certainly a strong push in this direction, which I support. Web services are based on the use of SOAP messaging. WS-Security's official name is "Web Services Security: SOAP Message Security". Hence, the focus on SOAP messaging. If one wishes to use other protocols, such as RPC, there are other security standards which are appropriate.
I understand and agree completely, and my own grid effort (TIGRE) is based on web services-based implementations of grid services only. I simply point out that it it technically possible to take the same WSDL and XML and (in some cases automatically) generate code that can implement the same grid services through other mechanisms. Stating the standards basis for security more generally than SOAP might allow other implementations of grid services that do not rely on SOAP messaging but are otherwise perfectly usable by a give community, that's all. I admit that there is not at present a large community clamoring for such a generalization, although it is technically achievable. I also completely agree on the push to web services for grid service delivery. There are plenty of technical issues to settle even within the scope of current implementations.
While there are certainly interesting AuthN topics to discuss which go beyond the identified 'express' work, I am very concerned about having two AuthN groups working in parallel. It has been difficult to achieve critical mass on OGF security standard's work and I fear we'll end-up with inadequate engagement on both efforts. I suggest we look seriously at combining these efforts. Is there a scope/sequencing of work which makes sense where the 'express' profiles are the first set of deliverables for a more broadly chartered group? I don't personally care if such a group is officially part of OGSA or the Security area.
I raised this issue at OGF20, but haven't heard from anyone regarding their opinion on having one versus two efforts.
The efforts are already essentially combined. We pulled back on pushing the OGSA-AuthN work forward in order to be able to complete work on the current document series. My sense is that this work is now reaching a mature state and that the charter work can go forward on defining the AuthN body of work. The HPC-profile work done and now going on can be regarded as the first set of output from this combined effort. Re. AuthZ, my suggestion (as a member and not a leader of that group) would be to button up the current set of documents as mentioned, which essentaially summarize the current situation for posterity and point to the other OASIS, XACML and WS-Trust work, put out that set of documents (which have been circulated and lack only formalized status for reference by the community), and ask David to look at the express profile work as we asked in the meeting. There is important AuthZ work to do in the future, but it is not clear to me that this needs more of an OGSA basis than the work above, and my preference would be to go on to the OGSA work for standards as to what needs to go out over the wire to support AuthN. Much of the remaining work on AuthZ can be handled by the individual AuthZ communities. 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 : ====================================================================
Alan, Comments and questions in-line. Alan Sill wrote:
The question to ask here is whether grids should move toward relying on web services as the basis for interoperability? There is certainly a strong push in this direction, which I support. Web services are based on the use of SOAP messaging. WS-Security's official name is "Web Services Security: SOAP Message Security". Hence, the focus on SOAP messaging. If one wishes to use other protocols, such as RPC, there are other security standards which are appropriate.
I understand and agree completely, and my own grid effort (TIGRE) is based on web services-based implementations of grid services only.
I simply point out that it it technically possible to take the same WSDL and XML and (in some cases automatically) generate code that can implement the same grid services through other mechanisms.
I doubt you will find any broad interest in developing standards for this. It is certainly not a commonly used approach that people have a lot of experience with. I fear going down this path will derail the proposed AuthN work.
While there are certainly interesting AuthN topics to discuss which go beyond the identified 'express' work, I am very concerned about having two AuthN groups working in parallel.
The efforts are already essentially combined. We pulled back on pushing the OGSA-AuthN work forward in order to be able to complete work on the current document series. My sense is that this work is now reaching a mature state and that the charter work can go forward on defining the AuthN body of work. The HPC-profile work done and now going on can be regarded as the first set of output from this combined effort.
I'm confused by your statement that they are "essentially combined". Perhaps you and Andrew can clarify? The scope and technical approach for the 'express' profile work is still being discussed, so it doesn't seem to be in a mature state. The plan seems to be to continue the 'express' work in parallel with a separate OGSA AuthN charter discussion. I'm still concerned potential AuthN contributors will have trouble engaging with two independent efforts, to the detriment of both. The HPCP work can certainly be seen as a precursor, but is an independent effort which is not an OGSA specification. Regards, Blair Dillaway
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. :-\
- 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. 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.
- 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 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. (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.
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 *****************************************************************
Attendees: Mark Morgan (UVa) Duane Merrill (UVa) Blair Dillaway (Microsoft) Steven Newhouse (Microsoft) David Chadwick (Kent U) Chris Kantarjiev (Oracle) Hiro Kishimoto (Fujitsu) ZackK Agenda Items: - Present the transition of these documents to target the WS-SecurityPolicy grammar (Duane Merrill) - Address any relevant trackers (Duane Merrill) Duane gave an overview of the transition from a Liberty-like security policy assertion mechanism for EPRs to a WS-SecurityPolicy based scheme. Ran through an example contained in all three profile documents that addresses components from each (Addressing, Transport, SOAP messaging). Discussion on whether or not to consolidate profile documents into one document. Pros: less "pointer chasing" to read. Cons: what to do about partial compliance, how to effect partial derivation for as-yet-to-be-created subprofiles, monolithic document paradigm inviting more policy-related complexity (such as AuthZ requirements). General consensus is to keep orthogonal ERP security profiling separate, lightweight. Discussion (spurred by comments from Frank, David, I believe) about adding/profiling mechanism for expressing AuthZ policy requirements (beyond simple credential/token-type statements), such as "You must be able to present a SAML token asserting your membership in group XYZ". While useful, consensus was that this type of profiling for EPR authZ policy should go into a separate profile for which separate conformance claims can be made. Because the documents were published earlier that afternoon, Duane recommended to the group that everyone review them and followup with discussion on the OGSAWG mailing list. ____________________ Duane Merrill dgm4d@cs.virginia.edu Computer Science Department University of Virginia
participants (7)
-
Alan Sill -
Blair Dillaway -
David Chadwick -
Donal K. Fellows -
Duane Merrill -
Frank Siebenlist -
Tom Scavo