- ogsa-authz-wg - lists.ogf.org

Authorization based on action parameters
by Olle Mulmo 21 Feb '05

21 Feb '05

FYI: Through the magic of GridForge, I was asked to "approve" this document. I'm still not sure what kind of approval that's requested, as this document seems more like meeting material / base for discussion than anything else: http://forge.gridforum.org/projects/ogsa-authz/document/ActionParameters/en… /Olle

2 1

EuroPKI 3rd Call for Papers
by David Chadwick 17 Feb '05

17 Feb '05

Dear All please find attached the third call for papers for the EuroPKI workshop. I am glad to announce that Carlisle Adams will be giving the keynote speech. So put the dates, 31 June-1 July in your diaries, and submit a paper if you have one. There is still time since there is a one week extension on the call for papers, which now closes on 27th Feb rather than 20th Feb. Regards David -- ***************************************************************** PLEASE NOTE NEW CONTACT DETAILS AS OF 1 JAN 2005 David W. Chadwick, BSc PhD Professor of Computer Science The Computing Laboratory, University of Kent, Canterbury, CT2 7NZ Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick(a)kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

Re: [AuthZ] Closing the Group
by Frank Siebenlist 26 Jan '05

26 Jan '05

I've added the "proper" mailing list to the cc-list this time ;-) David Chadwick wrote: > Dane > > Von has asked me to chair the next meeting of the group in Seoul. I > have agreed and already requested a meeting slot on Grid forge. Maybe > this should be the first meeting of a new group, or perhaps the last > meeting of the current group. Either way there is some unfinished > business to attend to, specifically the following: > > i) to add obligations to the second version of the SAML Authzn spec > ii) to add operation parameters to the second version of the SAML > Authzn spec > iii) to migrate the SAML Authzn spec to SAMLv2.0 (either version 1 or > version 2 of the SAML Authzn spec or both) > I'd like to add the XACML-2.0-SAML2.0 profile as an alternative source for an authorization query interface that we may want to consider. "http://www.oasis-open.org/committees/download.php/10525/XACML-2.0-SAML-PROF…" Even though the name "suggests" that it is very xacml specific, it can be viewed as a generic authorization query message exchange with some nice properties. Regards, Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 1

XACML "community meeting"
by Seth Proctor 25 Jan '05

25 Jan '05

[ this message has been bcc'd to a number of XACML-interested lists, so my apologies if you recieve multiple copies ... please forward to anyone who you think might be interested ] It's been a real pleasure to watch the XACML community grow over the last few years, and it's been just as nice to meet so many new people as a result. Sadly, I haven't met nearly as many of you in person as I would like to have. and I want to remedy this. I'm travelling to California in February, and while I'm there I'm going to setup an evening get-together for folks to meet, chat XACML, etc. The problem is that I don't know how many people are actually there, since many of the people I talk with daily are from all over the world. Sooo, if you're interested, please let me know. This would be some time between the 17th and the end of February, depending on when works best for everyone. If it turns out that no one is around, I'll try again for another time. Note that the RSA conference overlaps with this, and I hope that may draw a few people to the area. Please let me know soon, and I'll get to work on details. seth ps I live in the Boston area, and given enough interest, I'd be happy to setup something for this area too. Let me know if you want in!

1 0

SAML AuthZ Service / Web Services Security X.509 Certificate Token Profile
by Markus Lorch 22 Jan '05

22 Jan '05

Hi all, the SAML AuthZ Service document in section 6.1 requires us to use the Web Services Security X.509 Certificate Token Profile to encode certificate paths. I have been keeping my eyes open for an implementation of this standard for the last few months with no success. Do any of you know of an implementation or are working on one? (e.g. for the delegation service?) Do you have other implementations/ standards to encode certificate paths via XML? Btw, the reference to this standard in the document needs updating, the standard was finalized in the Spring of 2004, it is no longer a draft. - There is an old "Editor's note" in section 6.1.2 SubjectConfirmation Element from Von that can also be taken out. Maybe this can be fixed before its submitted to the editor (otherwise I'll repost in public comment) Thanks Markus ---------------------------------------------------------------- Markus Lorch Department of Computer Science Phone: +1 540 231 5914 Virginia Tech, m/c 106 Fax: +1 540 231 6075 Blacksburg, VA 24061, U.S.A. http://people.cs.vt.edu/~mlorch

2 2

Comments on "Use of SAML for OGSA AUthorization"
by dane＠fnal.gov 16 Jan '05

16 Jan '05

Here is my set of comments. Dane *** Substantive Issues *** Section 6.a.ii Element <SubjectAttributeReferenceAdvice> The schema fragment indicates an unbounded maxOccurs of element AttributeDesignator. Does the error response for a receiver overflow need to be specified or is this inherited from the SAML (or unnecessary since it's an advice element) ? Section 6.b, attribute Recipient The specification states the requirements for this attribute when the initiating ExtendedAuthorizationDecisionQuery contains a Recipient attribute, but does not state requirements when the initiating ExtendedAuthorizationDecisionQuery does not. Is it "MAY" or "SHOULD NOT" in that case? Section 7.a (Extended) AuthorizationDecisionQuery The "client MUST" at the beginning of this section seems to me to proclude the possibility of a client giving blanket authorization for some action (say the equiv of reading a webpage). Should the section rather start "An OGSA client SHOULD request an authorization decision. A client requesting an authorization decision MUST do so using either ..." ? Section 7.a X.509 Proxy Certificate Format Identifier Reference [ProxyCerts] seems to me should point to RFC 3820 and be normative. What is the reason to reference (only) the workshop paper ? Section 7.a.2.i SubjectConfirmation Element The condition "authenticated using the Grid Security Infrastructure" would seem to me to require a normative reference in a normative section. Is there a normative reference available or should this be defined here ? Section 7.a.2.ii.1 Grid Services The condition "is a Grid service" would seem to me to require a normative reference in a normative section. Is there a normative reference available or should this be defined here ? Section 7.a.2.ii.2 Wildcard Resource Bullet 1 under this section states the desire to be "to learn the subject's rights on all the resources of which the authorization service is aware." This seems like an unbounded desire and not the obligation we wish to imply on the authorization service. Should this rather be "all resources for which the authorization service believes itself to be authoritative" ? Section 8.c Full WSDL This section shows WSDL to create an "OGSI SAML Grid Authorization Service". However, this doc is about using SAML for OGSA authorization. This rather read "OGSA SAML ..." ? I would suggest that Section 17 was a useful primer for discussion/creation of this document, but should be removed from the final form of this specification document (keep them clean). It would be nice to capture this text as a working document in the WG as a short background summary. Implementers with questions (ie. the primary audience for this document) about SAML should be referred to the normative SAML docs. *** Editorial comments *** The "ogsa-saml" XML namespace isn't at the URI listed. Is this a chicken and the egg problem or a problem with the website ? (there are others as well inside the doc) Section 4, paragraph 2, sentence 1, should read "... and it is upon this version of SAML ..." Section 5a, subbullet 1, sentence 3, should read "... if all actions were allowed or ..." Section 6.a, attribute RequestedSigned, sentence 2: should this read " This element SHOULD contain the QName..." ? Section 6.b, element "Recipient" Should this element me tagged "[Optional]" with the explanitory text below or is the convention to leave such conditionals untagged ? Section 6.b, paragraph 3 has a spelling error for <SimpleAuthorizationDecisionStatement> (missing the 3rd "i") Section 7, paragraph 1, sentence 2, should read "... used to meet OGSA requirements ..." (transposition) Section 7.a.2 Should the phrase "domain of resources" be defined ? <Is this defined in the AuthZ glossary ?> Section 7.a.4 Should the list of things an Evidence element may contain be enumerated as a list itself or left inline (I found referents tough to determine clearly). Section 7.a.2.i The editor's note on X509PKiPathv1 remains. This needs to be resolved and removed. Section 7.a.2.ii Resource String Should this sentence begin rather "The Resource string MUST be "*" ... " ? Section 7.a.2.iii.2 Grid Service Data Access There seems a number mismatch in sentence 1. Should it read rather "... (SDEs) associated with a Grid Service ..." Section 7.a.2.iii.2 (various places) Should the text read rather "The action string SHOULD contain the QName..." Section 7.b.i Conditions Element, Paragraph 2, sentence 3 should read "... using, for example, elements of XACML." (I'm not sure if the section numbering change is an artifact of my OpenOffice or the .doc) Section 7.b.iii AuthorizationDecisionStatement Element, paragraph 2 should read "... render a decision due to ..." Section 7.b.iv AttributeStatement Element should expand the RBAC acronym (first use) Section 7.b.v Signature Element should read "... places no constraints on ..." Section 8.a.ii supportsIndeterminate should read "... may not allow the return of indeterminate."

3 4

OGSA-Authz meeting at GGF13 - need meeting chair
by Von Welch 07 Jan '05

07 Jan '05

Folks, For a couple of reasons, I will unfortunatly not be attending GGF13. If someone else who is attending is willing to chair an OGSA-Authz meeting, I will help schedule and make an agenda. You probably need to speak up in the next week to make sure it happens. Von

1 0

CfP: Ottawa Workshop on "New Challenges for Access Control"
by Frank Siebenlist 21 Dec '04

21 Dec '04

As I know that access control and related policies are high on our agendas, the attached may be of interest. Securely yours and Happy Holidays, Frank. --- Call for Presentations Ottawa Workshop on: "New Challenges for Access Control" Present day information technology architectures can enable new business models and reduce the cost of doing business. However, legislative and regulatory pressures impose severe penalties on those who exploit these architectures without due consideration to privacy and integrity. Unfortunately, current technology is insufficient for addressing the new access control challenges and this has led to a renewed interest in effective approaches for addressing these challenges. The information security community is seeking new, innovative techniques to help it navigate this minefield with cost-effective tools for managing access control and privacy policies and enforcing them consistently across a broad range of applications, including email, file transfer, the Web and Web services, removable media, instant messaging, databases and repositories. Recent developments in access control and privacy include the development of a standard model for role-based access control, standard expression languages for specifying access control policies and the application of access control methods to structured resources, such as • XML documents, • personally-identifiable information, • digital rights, • interfaces in a service-oriented architecture, • delegation of permissions, • role-based access control, • networks and computers and • business-process workflow. The Ottawa Centre for Research and Innovation, in collaboration with Entrust Inc., the Université du Québec en Outaouais and the University of Ottawa is holding a one-day workshop entitled “New Challenges for Access Control” in Ottawa on 27th April 2005. The workshop will provide an opportunity for practitioners and researchers to share their ideas and experiences on such topics as: • Access control requirements, • Access control models, • Access control policy expression languages, • Access control and privacy policies • Access control architectures, • Policy management architectures and • Tools for developing and analyzing access control and privacy policies. Proposals covering any of the following aspects are encouraged. • Research, • Implementation experience, • Applications and • Case studies. Tutorial and review presentations are also welcome. The program committee invites you to submit a proposal for a presentation or panel discussion that addresses one or more of the above topics. The program committee may adapt or restructure proposals submitted in order to ensure an interesting and technically compelling program. The main selection criterion will be that the abstract provides a clear and complete presentation of some important aspect of the workshop topics. Presentations will be 30 minutes in duration, including question and answer time. Panel sessions will be 50 minutes in duration. Proposals for panels should include the title, 3 to 4 potential panelists (name and/or role) and proposed format (e.g. Q&A, short presentations, etc.). The organizers will publish proceedings of the workshop. Authors should arrange for any necessary releases for publication prior to submission of their proposal. To submit a proposal, please send the following information by email to ncac05(a)entrust.com: • The full contact details (name, affiliation, email, phone, postal address) of one presenter who will act as the primary contact for the presentation or panel discussion, • The full list of authors, • A 1-page abstract outlining the subject and key points of your presentation or panel discussion or • A short slide presentation on the topic. All submissions will be acknowledged. Important dates: Abstract deadline 4 Feb 2005 Presenter notification 3 Mar 2005 Slides deadline 14 Apr 2005 Workshop 27 Apr 2005 The program committee consists of the following • Carlisle Adams (U of O) • Kamel Adi (UQO) • Anne Anderson (Sun Microsystems) • Eugen Bacic (Cinnabar) • Dan Craigen (ORA) • Petre Dini (CISCO) • Ramiro Liscano (U of O) • Luigi Logrippo (UQO) • Tim Moses (Entrust) • Seth Proctor (Sun Microsystems) • Steve Zeber (DRDC) -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

FW: [OGSA-AUTHZ] WG Last Call: Use of SAML for OGSA Authorization
by Markus Lorch 16 Dec '04

16 Dec '04

> > I think this is due to the fact that AuthoizationAdvice is > > an abstract type for which instantiations of AuthorizationAdvice > > change the tag name to e.g. SubjectAttributeReferenceAdvice and > > this tag name thus has to be recognized directly by the > > parser that reads the ExtendedAuthorizationDecisionQuery. > > I think if you write the schema properly, the parser will > recognize that > SubjectAttributeReferenceAdvice extends AuthorizationAdvice, and > therefore is allowed instead of the latter. I am not sure what the > situation is with the schema used by > ExtendedAuthorizationDecisionQuery. > Thanks Sassa, my comment is superfluos then if this issue can be avoided though a different schema / different implementation. My problem was less with the schema and the schema validation but more with how the parser as an extension to OpenSAML is implemented. If you happen to have an extensible example of how to do this I would love to take a look and learn. Markus

1 0

WG Last Call: Use of SAML for OGSA Authorization
by Von Welch 16 Dec '04

16 Dec '04

I am putting the document "Use of SAML for OGSA Authorization" into working group last call. Please send any comments to the group list by January 10th. As discussed at GGF12, I have taken the May 14th version (prior to the Obligations work) made the changes indicated at the end of the email. The resulting document is dated December 14th and can be found in Grid Forge, or directly using the URL appended below. I understand that at least one group member wanted to get Obligations into this document, but I believe this document captures a vital snapshot of implementations in its own right and should be move forward. It can be followed by another version with Obligations. Those feeling strongly about this are encouraged to indicated to the working group as part of the Last Call process. I expect to follow this with a Last Call on the Attributes document shortly. Von Word version: https://forge.gridforum.org/docman2/ViewProperties.php?group_id=119&categor… PDF version: https://forge.gridforum.org/docman2/ViewProperties.php?group_id=119&categor… Changes from May, 2004 to December, 2004 version: * Added Appendix C giving an example of how GT4 creates URIs from WS-Addressing elements. * Marked Recipient field in 5.1 as depreciated since it is insufficient to stop replay attacks.

3 2