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

some thoughts on attribute mapping of an XACML request context
by Takuya Mori 18 Apr '07

18 Apr '07

Hi, The following is some thought on attribute mapping of an XACML request context. I hope it will be a good input for today's discussion. Thanks, Takuya ---- Feb. 13, 2007 Takuya Mori a note on attribute mapping of an XACML request context 1. Subject Attributes Any attributes asserted in credentials of a subject attached to a request message should be taken into the consideration of the authz decision. Therefore, such attributes should be embedded into an XACML request context as its subject attributes. The followings are an example of such credentials: - X.509 Certificates -- public key certificates -- attribute certificates -- proxy certificates - VOMS Attribute Certificates (actually, it's a kind of X509 attr certs) - privilege credeitnals such as PERMIS, CAS, ... credentials - others? Username/Password Tokens?, Kerberos Tickets? - ... [AuthzFunc] document defines four types of interactions between authorization functional components. In case of two PEP Context Handler Models, because the validity of the credentials are validated on the PDP side, the whole credentials of the subject should be passed to the PDP in an XACML request context. Therefore, it is needed to define a subject attribute format of the XACLM request context which can hold a binary credential within it. On the other hand, in case of two PEP Context Handler Models, the validity of the credentials are validated on the PEP side and the validated attributes are passed to the PDP in an XACML request context. Therefore, there is a need to define a rule to map such validated attributes into XACML subject attributes. As a conclusion, regarding with our [XACMLProfile] document, what we need for our subject attribute profile is: 1) a way to embed a binary credential into a subject attribute of an XACML request context. 2) a way to map an attribute of a generic credential such as X.509 public key certificate into a subject attribute of an XACML request context. 3) a way to map an attribute of popular credential formats such as VOMS attribute certificate, Shibboleth attribute assertions, etc... The scope of credential types to support by the [XACMLProfile] document should be defined based on the requirements by the community. In case of NAREGI, X.509 proxy certificates as well as VOMS attribute certificates are used for authentication and authorization. And NAREGI's AuthZ service is based on "PEP Context Handler + Push" model defined in the [AuthzFunc] document. The subject attributes used in NAREGI for AuthZ are shown below. - UserDN: ID: "urn:oasis:names:tc:xacml:1.0:subject:subject-id" Value: User's "Globus ID" (in String format) - VOMS VO Name Attribute: ID: “naregi:vo:voName” Value: VO Name (in URI format) - VOMS Group Attribute: ID: “naregi:vo:group” Value: Group Name (in String format) - VOMS Role Attribute: ID: “naregi:vo:role” Value: Role Name (in String format) - VOMS Capability Attribute: ID: “naregi:vo:capability” Value: Capability Name (in String format) The IDs described above are tentative and it is preferable to have standardized IDs for them. 2. Resource Attributes [XACMLProfile] document specifies that the resource attribute of an XACML request context should be the value of wsa:To header of an incoming request message, which is an endpoint reference of a service interface to which the request is sent. [OGSA-WSRFBasicProfile] docuemnt defines a set of profiles to embed reference properties into an endpoint reference which enables to specify a WS-Resource, a stateful resource behind a service interface of a Web Service. Therefore, the profile specified in the current [XACMLProfile] document is sufficient for specifying a WS-Resource in an XACML request context. There may be a case where some service providers need to make an authorization decision on information appeared in a message body. For example, a user who is submitting a job to an job execution service can request some amount of computing resources in a JSDL document and a service owner of the job execution service would like to make an authorization decision based on the amount of comuting resources requested in the JSDL document. Because information which appeared in a message body is consumed by a service, the authorization decision discussed here can be said as application level authorization. In my opinion, a support for such authorization decision on middleware level is helpful for application developers because not all such the developers can design authorization mechanisms for their application. In case of NAREGI's AuthZ service, in order to address the requirement for application level authorization, Resource Attribute Filtering Mechanism, a flexible and configurable method to specify a mapping between resource descriptions in a request message and resource attributes of an XACML request context is introduced. RAFM is configured by a Resource Mapping Description which defines such mapping rule and only a owner of a service can configure it. The following is an example of a Resource Mapping Description. List.1: An example of a Resource Mapping Description ---- 01: <resource_maps> 02: <namespaces> 03: <namespace prefix="ns1" value="http://schemas.ggf.org/jsdl/2005/06/jsdl"/> 04: </namespaces> 05: <map> 06: <input_element>//ns1:Resources/ns1:TotalResourceCount/ns1:Exact </input_element> 07: <xacml_resource_attribute_id>naregi:TotalResourceCount </xacml_resource_attribute_id> 08: </map> 09: </resource_maps> ---- 02..04: a <namespaces> element defines namespace declarations that are used in an XPath expression in a <input_element> element. 06: a value of an <input_element> is an XPath expression for specifying a resource description in a message body of a request message. 07: a value of an <xacml_resource_attribute_id> element is an resource attribute id that will be used in an XACML request context to specify the resource specified by the XPath expression in the line 06. The description above will make the RAFM to convert the fragment of an JSDL document shown in List.2 to the XACML resource attribute described in List.3. List.2: a fragment of an JSDL document ---- 01: <Resources> 02: <TotalCPUCount> 03: <Exact>1</Exact> 04: </TotalCPUCount> 05: </Resources> ---- List.3: an example of a resource attribute of an XACML request context ---- 01: <Resource> 02: <Attribute AttributeId="naregi:TotalResourceCount"> 03: <AttributeValue>1</AttributeValue> 04: </Attribute> 05: </Resource> ---- There may be an issue that a malcious user may specify a spoofed value in a message body which can cause the authorization component to make a false decision on the service access. In my opinion, in order to provide some service to a user, a service owner need to trust a content of the reqest message in some extent, because the content will be used for some computation behind the service. Therefore, the information in the request message can also be used for authorization decision with the same level of the trust that the computation relys on at the service owner's choice. A. References [XACMLProfile] Use of XACML Request Context to access a PDP, David W. Chadwick et al. [AuthzFunc] Functional Components of Grid Service Provider Authorisation Service Middleware, David W. Chadwick et al.

3 2

background materials for OGSA Teleconference - Security - Apr. 9, 2007
by Alan Sill 09 Apr '07

09 Apr '07

As background material for the discussion at teh OGSA-WG meeting today, I would like to have people look at the "IdM Tools for Grids" section of the following session materials from the Educause site, consisting of proceedings from the Southwest Regional Conference 2007 session on "Case Studies for Identity Management for Virtual Organizations" in Feb 2007: http://educause.edu/ir/library/pdf/SWR07058.pdf or http://tinyurl.com/2amsmw Other session contributions are included there from 07, Paul Caskey (UT System) and Jerry Perez (TTU for SURAgrid), which you may find interesting also. In summary, we need a clear, consistent set of charters for grid standards development for the use of various technologies in a grid context. Work has started with several co-chartered groups and organizations within OGF, and I think we should keep good communication among them. Details of the meeting, for those who may wish to participate and have not already received the announcement: > From: Andreas Savva <andreas.savva(a)jp.fujitsu.com> > When: 2007年4月10日火曜日 7:00-8:00 (GMT+09:00) 大阪、札 > 幌、東京. > > *~*~*~*~*~*~*~*~*~* > > <pre> > [Hiro is unavailable for this call and I will be standing in for him.] > > The dial-in number for Monday; > US: +1 718 3541071 (New York) or > +1 408 9616509 (San Jose) > UK: +44 (0)207 3655269 (London) > Japan: +81 (0)3 3570 8225 (Tokyo) > PIN: 4371991 > More information: > - https://forge.gridforum.org/sf/go/wiki1477 > > Screen share service will be provided. > URL: http://ogsa.glance.net/?key=0409 > More explanation: > https://forge.gridforum.org/sf/go/wiki1584 > > Note: ** OGF IPR POLICY APPLIES ** > http://www.ogf.org/About/abt_policies.php > > <====SLOT 1: STARTS 5pm; ENDS 6pm CDT=====> > > 1) Early discussion (10 min) > Social study: > - https://forge.gridforum.org/sf/go/wiki1717 > Note taker assignment > Roll call > Agenda bashing > > 2) Security (Andrew G and Alan S) > > - Action Item review > > * AI-0315a: Andrew et al to develop Express Authentication > Profile, > HPC Profile (Andrew to talk to them), Frank (review), > Michel Drescher (Unicore), (Steve McGough) GridSam, > > * AI-0315b: Andrew to contact GIN (Erwin Laurie) about existing > (delegation free) use cases. > > - Use case review. > UVA team will post a use case document. The use case document prepared by the UVa team is attached below for the benefit of those who may not have received it. 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(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 0

Telecon minutes
by David Chadwick 03 Apr '07

03 Apr '07

Dear All the minutes from today's telecon can be found on the grid forge at http://forge.gridforum.org/sf/go/doc14377?nav=1 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(a)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 *****************************************************************

1 0

Telecon
by David Chadwick 03 Apr '07

03 Apr '07

Hi All the telecon is due to start in approx 30 minutes. Please RSVP if you intend to participate. Tel: +1-605-475-8500 Conference Id: 5780044 skype:+99008275780044 The time is 3pm UK, 4pm Europe, 10am East Coast, 7am West Coast, midnight Japan. the Agenda is as follows 1. Roll Call 2. Note taker 3. Discussion of Takuya's email of 13 Feb about attribute mapping. 4. Progression of profiles. 5. AOB 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(a)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 *****************************************************************

3 2

[ogsa-wg] Proposed agenda for March 29 call
by Hiro Kishimoto 28 Mar '07

28 Mar '07

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 29 Thursday from 8am - 10am (CDT). We subdivide the call into two 1 hour slots and the 2nd slot starts 9am. Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +(210) 234-7446 PIN: 71815 See more information: - https://forge.gridforum.org/sf/go/wiki1477 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0329 See more explanation: https://forge.gridforum.org/sf/go/wiki1584 Note: ** OGF IPR POLICY APPLIES ** http://www.ogf.org/About/abt_policies.php <SLOT 1: STARTS 8am; ENDS 9am CDT> 1) Early discussion (20 min) Social study notification - https://forge.gridforum.org/sf/go/wiki1717 Note taker assignment Roll call Agenda bashing 2) Information/data modeling (Ellen Stokes, 50 min) Telecon minutes approval (March 22 call, F2F) - https://forge.gridforum.org/sf/go/doc14251 - https://forge.gridforum.org/sf/go/doc14327 Ellen will write up initial data tag proposal. <SLOT 2: STARTS 9am; ENDS 10am CDT> 3) OGSA-AuthZ joint call (David Chadwick, 50 min) Telecon minutes approval (March 8 call) - https://forge.gridforum.org/sf/go/doc14291 4) Wrap up (10 min) AOB <*NEXT CALL*> https://forge.gridforum.org/sf/go/wiki1477 April 2, 2007 (Mon) * 5-6pm: Roadmap (Chris Jordan) April 5, 2007 (Thu) * 8-9am: Profile Interop (Hiro) * 9-10am: Logistics and Administrative (Hiro Kishimoto) April 9, 2007 (Mon) * 5-6pm: QoX (Andrew) * 6-7pm: Logistics and Administrative (Hiro Kishimoto) April 12, 2007 (Thu) * 8-9am: Glossary (Jem) * 9-10am: EMS Information Services (Andrew) <*ACTION ITEMS*> https://forge.gridforum.org/sf/go/wiki1569 -- Hiro Kishimoto

1 0

Use of Multiple IdPs/AAs
by David Chadwick 26 Mar '07

26 Mar '07

Dear Colleague The UK JISC and US Internet2 would like to find out user needs and requirements for the use of attributes, issued by multiple authorities, in federated authorisation. The ultimate intention is to develop open source software that satisfies these requirements, for free distribution globally. It would greatly help us if you could circulate this questionnaire far and wide, and answer it yourself if you feel able. The questionnaire is unlimited in its circulation, but we would like answers by 23 April. sorry for any cross postings. yours sincerely David Chadwick and Nate Klingenstein

1 0

Fwd: Web Services Profile of XACML
by Tom Scavo 17 Mar '07

17 Mar '07

FYI ---------------------------------------------------------------------- Web Services Profile of XACML (WS-XACML) Anne Anderson, OASIS Presentation This PDF document summarizes a presentation made at the OASIS XACML TC Face-to-Face meeting on 13-March-2007. Outline: Web Services Policy Background; XACML Web Services Policy Assertions; XACML Assertion Format; XACML Assertion Matching; Defined XACML Assertions [XACMLAuthzAssertion, XACMLPrivacyAssertion]; New XACML Functions and Attribute Identifiers; Open Issues. Abstract from "Web Services Profile of XACML (WS-XACML) Version 1.0": "This document specifies ways to use XACML in the context of Web Services for authorization, access control, and privacy policies. It specifies four types of information. (1) An authorization token or credential based on XACML to be used in a Web Services context for conveying an authorization decision from a trusted third party to a Web Service. (2) A policy Assertion type based on XACML elements for use with WS-Policy or other schemas and protocols; this Assertion may be used to convey both requirements and capabilities related to authorization, access control, and privacy for Web Service clients and for the services themselves. This Profile specifies standard formats, matching semantics, and usage guidelines for two Assertions derived from this type: one for authorization policies and the other for privacy policies. (3) Some ways in which Attributes for a client MAY be passed to a Web Service as part of a SOAP message in such a way that they can be authenticated as having been issued by a trusted authority. These Attributes may be used by the Web Service in evaluating the internal XACML policies of a service or enterprise that are relevant to a given Web Services access. (4) How to express P3P policy preferences and match them using the new Assertion based on XACML." http://xml.coverpages.org/xacml.html#Anderson-WS-XACML-F2F200703 See also WD 08: http://www.oasis-open.org/committees/download.php/21490/xacml-3.0-profile-w… ----------------------------------------------------------------------

1 0

Globus impl of SAML 2.0 Profile of XACML
by Tom Scavo 16 Mar '07

16 Mar '07

FYI, work has begun to incorporate an implementation of the SAML 2.0 Profile of XACML into Globus Toolkit: http://www.globus.org/mail_archive/jwscore-dev/2007/03/msg00019.html Tom Scavo NCSA

4 6

Re: [OGSA-AUTHZ] [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007
by Blair Dillaway 09 Mar '07

09 Mar '07

Nate, I believe you mis-understood what I was trying to say. If one wishes to write an attribute-based authorization policy for a resource, one must know what attributes a client could provide. I can't, for example decide to write a group-based authZ policy unless I know some IdP(s) will tell me about what groups a client is affliated with and how that group attribute is encoded. As you mention there could be several different group attribute types used by different IdPs. There has to be some way for SPs to discover the IdPs vocabulary. This tends to be handled in various ad hoc ways and can be difficult to discover and track over time. I was suggesting that having a standard way of doing this for large distributed systems is valuable. This is completely independent of whether client attributes are pushed, pulled, sent via intermediaries, and how an SP decides whether that info is trustworthy. Regards, Blair ________________________________ From: Nate Klingenstein [ndk(a)internet2.edu] Sent: Thursday, March 08, 2007 3:39 PM To: Blair Dillaway Cc: Alan Sill; Hiro Kishimoto; OGSA AUTHZ WG; ogsa-wg; OGSA Authentication WG BoF Subject: Re: [ogsa-authn-bof] Minutes of OGSA-WG + OGSA-AuthZ Joint telephone call 8 Mar 2007 Blair & Andrew, I'm not sure the former -- having authorities describe what they're authoritative for -- is entirely desirable or practical. When we discuss "authoritative for xyz data" in the context of identity information, I think it's necessary to append "for person abc" for it to have much meaning. My IdP isn't your IdP, the same attribute may be expressed by multiple authorities, and my release policies are likely to vary by SP, so this appendix adds a great deal of complexity. For each SP to manage and interpret the matrix of attributes/authorizations/identifiers and authorities for every principal they deal with strikes me as unreasonable and unnecessarily compromising of privacy. This gets back to my core philosophy: the IdP should push everything it can, and for what it can't push(e.g. things it's not authoritative for), it should push the information needed to retrieve the additional attributes/authorizations, ideally via a discovery service associated with that user. The discovery service can dynamically handle the user/authority/request pile and collect either raw data or pointers as appropriate. If someday there's an intelligent client, then it can manage attribute and authorization locations for a principal internally, which is even better. That said, I do think conversely there's value in SP's advertising the attributes or authorizations they need in order to reduce the need for callback queries, as those requirements are likely to be relatively static and unlikely to vary by IdP or user. There are additional questions to consider when talking about attribute metadata, though. Does some third party, e.g. a federation or a CA, need to vouch for my IdP's claim that it's able to assert staff(a)microsoft.com<mailto:staff@microsoft.com>? Will that third party be universally trusted by all the SP's I deal with? The SP retains, and will always have, the right to validate and interpret information it receives. I believe it's the job of the authorities, intermediaries, and flows to preserve as much of that information as is practical so the SP has the basis for a decision once the information arrives. Whether the SP would like to rely on the certification of an external authority or its own judgment, it's able to do so. Any standard should recognize both sides of this coin. Anyway, regardless of your own beliefs, the expression of both attribute expression and request is possible today by using the <RequestedAttribute> and <saml:Attribute> elements from the SAML 2.0 metadata profile. Inasmuch as privileges and identifiers(NameIDFormat can be declared too, FWIW) can be thought of as attributes, I think this supports what you'd like to do, but not at the web services layer. The Higgins project seems to be trying to do this using WSDL through the IdAS API, but I don't know enough about it to talk authoritatively. ID-WSF and WS-Federation have somewhat coarse-grained abilities to express where attribute information is located as well. Does this make any sense to you? Nate. On 8 Mar 2007, at 22:40, Blair Dillaway wrote: [blaird] I see two important aspects to this. First, authorities need to be able to communicate what they are authoritative for (attributes, types of principal identities, ...) so that resource admins can know what they can rely upon in developing authZ policies. Second, resources need to be able to communicate what authenticated information they require (token types, which authorities, ...). WS-SecureConversation (http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-secur…) could potentially be profiled as a way to do the latter. I'm not aware of an existing std that addresses the former.

2 2

[ogsa-wg] Proposed agenda for March 8th call
by Hiro Kishimoto 08 Mar '07

08 Mar '07

Hi all, The following is a proposed agenda for OGSA-WG telecon on March 8th Thursday from 7am - 9am (CST). We subdivide the call into two 1 hour slots and the 2nd slot starts 8am. See the following wiki page for detail. - https://forge.gridforum.org/sf/go/wiki1703 Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +(210) 234-7446 PIN: 71815 See more information: - https://forge.gridforum.org/sf/go/wiki1477 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0508 See more explanation: https://forge.gridforum.org/sf/go/wiki1584 Note: ** OGF IPR POLICY APPLIES ** http://www.ogf.org/About/abt_policies.php <SLOT 1: STARTS 7am; ENDS 8am CST> 1) Early discussion (20 min) Note taker assignment Roll call Agenda bashing 2) OGSA-AuthZ-WG joint call (David Chadwick and David Snelling, 50 min) <SLOT 2: STARTS 8am; ENDS 9am CST> 3) March F2F meeting logistics (Hiro Kishimoto, 50 min) Telecon minutes approval (Feb. 26 slot 2: Logistics) - https://forge.gridforum.org/sf/go/doc14255 F2F logistics update (if any) To complete F2F agenda - https://forge.gridforum.org/sf/go/wiki1685 4) Wrap up (10 min) AOB <*NEXT CALL*> https://forge.gridforum.org/sf/go/wiki1477 Mar. 12 (Mon) 4-6pm: No call ?? Mar. 14-16 F2F meeting at Oracle Headquarters. <*ACTION ITEMS*> https://forge.gridforum.org/sf/go/wiki1569 <*DRAFT MINUTES*> https://forge.gridforum.org/sf/go/wiki1716 -- Hiro Kishimoto

5 5