February 2007 - ogsa-authz-wg

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

Re: [OGSA-AUTHZ] Web Services (Policy?) profile of/for XACML
by David Chadwick 27 Feb '07

27 Feb '07

Hi Anne this is good news, since the "SAML 2.0 profile of XACML v2.0" is the one we have currently used in our OGF draft for a grid PEP talking to a PDP. We had been informed at a previous OGF meeting that this profile was now deprecated by OASIS, and we were therefore looking for a replacement. But now we will not need to regards David Anne Anderson - Sun Microsystems wrote: > The original SAML 1.0 Authorization Decision Query and Statement were > "frozen" as of SAML 2.0, with a reference to the "SAML 2.0 profile of > XACML v2.0" as a suggested replacement. > > The "SAML 2.0 profile of XACML v2.0" is very much alive and has not been > deprecated; it is a full OASIS and ITU-T Standard. You can find a copy > on the XACML TC Home Page along with the other XACML 2.0 specifications: > http://www.oasis-open.org/apps/org/workgroup/xacml/manage/edit_notes.php#XA…. > There were some errors in the spec and schemas that are corrected in > the "SAML 2.0 profile of XACML v2.0 Errata" available at > http://www.oasis-open.org/committees/download.php/15447/xacml-2.0-saml-erra… > > > The XACML TC is updating the "SAML 2.0 profile of XACML" as part of its > XACML 3.0 release. The updates are intended to be backwards compatible, > and consist primarily of some additions to support the XACML 3.0 > Administrative Policy specification, such as the ability for a PEP to > send a policy to be evaluated along with the request context. The draft > of this update is available at > http://www.oasis-open.org/committees/download.php/18921/xacml-2.0-profile-s… > I should be issuing a new draft before too long. > > Please let me know if you have any further questions. > > Regards, > Anne > > David Chadwick wrote On 02/21/07 15:29,: >> Hi Yuri >> >> firstly we have a lot of opportunity to feed our comments into Anne, >> the author, and I am sure she will be very receptive to our helpful >> input. >> >> Concerning its purpose, it can be used in negotiation for the sender >> to say what his requirement are from the other party, and what his >> capabilities are for providing a service to the other party. However, >> this is not really what we want from this service. We simply want the >> ability to provide an XACML request context in a secure manner to a >> remote PDP, and to obtain an XACML response context from the PDP. >> Which is why the SAML profile (that is now deprecated) was actually >> ideal for us (and why my first OGF spec was based on it). So my >> question to Anne would be, Can we make sure this new spec has the same >> functionality (at least) as the previous SAML spec. >> >> regards >> >> David >> >> >> Yuri Demchenko wrote: >> >>> Hi David, >>> >>> I looked at the document your sent and was a bit confused to position >>> it among other standards in use and our work. >>> >>> Before we can discuss some minor detail, I want to say that title is >>> a bit misleading. They call it "Web Services Profile of XACML >>> (WS-XACML)" but actually it is Web Services Policy (WSP) >>> profile/extensions for (using) XACML in WSP style policy definition. >>> >>> They provided good use cases in Introduction, and correctly described >>> XACML AuthZ token (section 2). >>> >>> For me, it is not clear their definition of XACMLAuthZAssertion >>> (section 3). Is this an assertion or policy statement? >>> >>> "An XACMLAuthzAssertion represents an XACML authorization, access >>> control, or privacy policy that applies to the target of the >>> wsp:Policy instance in which it appears. The Assertion MAY be used by >>> a Web Service to express or publish its authorization, access >>> control, or privacy requirements or its capability of complying with >>> requirements imposed by a client. The Assertion MAY be used by a Web >>> Services client to express or publish its authorization, access >>> control, or privacy requirements requirements or its capability of >>> complying with requirements imposed by a Web Service. Two instances >>> of such an Assertion MAY be matched to determine whether they are >>> compatible, and, if so, which requirements and capabilities are >>> compatible." >>> >>> Also I didn't find support for so much expected cryptographically >>> valid/ensured attributes. >>> >>> So, what possibilities do we have to give our comments to the author? >>> >>> Yuri >>> >>> >>> David Chadwick wrote: >>> >>>> is attached. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> -- >>>> ogsa-authz-wg mailing list >>>> ogsa-authz-wg(a)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(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

XACML profile
by David Chadwick 22 Feb '07

22 Feb '07

is attached. -- ***************************************************************** 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 *****************************************************************

2 4

minutes of yesterdays telecon
by David Chadwick 22 Feb '07

22 Feb '07

Are now on the grid forum at http://forge.gridforum.org/sf/go/doc14236?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 *****************************************************************

3 7

[Fwd: Conference Call Confirmation]
by David Chadwick 14 Feb '07

14 Feb '07

Dear All here are the telecon details for those of you who did not receive a specific invite from the conference system regards David -------- Original Message -------- Subject: Conference Call Confirmation Date: 12 Feb 2007 15:16:45 -0800 From: Conference Call Reservation Agent <reservations(a)conferencemgr.com> To: David Chadwick <d.w.chadwick(a)kent.ac.uk> Your Conference Is Confirmed David Chadwick, the conference call you scheduled has been confirmed. Any invitations you elected to send to the Participants have been mailed. *Conference Details* Scheduled Conference Date: 13 February 2007 Scheduled Start Time: 15:00 Greenwich Mean Time Scheduled End Time: 15:55 Greenwich Mean Time Scheduled # of Participants: 6 Type of Conference: Web-Scheduled Standard Primary Dial-in Number: 0844.888.8888 (UK 5p National Rate) Alternate Dial-in Numbers: If your conference includes Participants located outside of the U.K., you can choose more than one dial-in phone number. As long as everyone participating in your conference enters the same Participant Access Code, they will be joined together. # +44.870.088.5706 (For Callers Outside of the U.K.) # 01805.004.102 (For Callers in Germany) Participant Access Code: 678876 Conference Controls: # Conversation Mode (all Participants can be heard) # Entry Chimes - Enabled # Exit Chimes - Enabled Note: The Organiser Access Code is only necessary for use of enhanced conference controls. Otherwise, you can just use the Participant Access Code. E-mail Invitations: 8 Sent Subject: OGSA Authz Telecon Comments/Agenda: Agenda 1. Roll Call 2. Note Taker 3. Implications of carrying attributes and credentials within the same protocol 4. Globus proposed Assertion Validation Service 5. Progression of XACML protocol profile 6. AOB Invitation Recipients: alan sill Alan.Sill(a)ttu.edu Frank Siebenlist franks(a)mcs.anl.gov rachana ranantha(a)mcs.anl.gov Takuya moritaku(a)bx.jp.nec.com Tom Scavo trscavo(a)gmail.com Vincenzo vincenzo.ciaschini(a)cnaf.infn.it Von Welch vwelch(a)ncsa.uiuc.edu yuri demch(a)chello.nl /Conference Booked by David Chadwick on 12 February 2007 at 23:16/ Conference Touch-Tone Quick Reference Touch-tone Controls 5, 7, 9 and # are available only to the conference Organiser † Conference Muting Modes: Conversation Mode, Q&A Mode, Presentation Mode ‡ Chimes settings: Entry on/Exit on, Entry on/Exit off, Entry off/Exit on, Entry off/Exit off See you there! -- ***************************************************************** 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

telecon
by David Chadwick 14 Feb '07

14 Feb '07

Has started now -- ***************************************************************** 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

Next telecon
by David Chadwick 13 Feb '07

13 Feb '07

Hi All The next telecon will be on Tuesday 13 February 2007 at 7:00 US West Coast 10:00 US East Coast 15:00 UK 16:00 Europe 00:00 Japan the agenda will be sent out shortly. Could all those who are likely to participate tell me, and then you will get notification directly from the conference management system. Unfortunately I cannot enter the Authz mailing list as a conference participant so that everyone is told the details 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://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************

1 0

OGSA-Authz-WG meeting minutes v2: OGF Jan 29 session
by Von Welch 08 Feb '07

08 Feb '07

Here are the minutes with all corrections and comments that I have seen. Von ---- * Preamble David brought meeting to order Circulated OGF IP sign-in sheet Von volunteers to scribe * Telecon Update Decision: Once every two months, we will take one of the OGSA-WG phone call slots to report to the larger community. Next date will be March 8th. Decision: Telecon dates February 13th March 7th April 3rd April 23rd * "Functional Components of Grid Service Provider Authorisation Service Middleware" available from http://forge.gridforum.org/sf/go/doc13968?nav=1 Latest version is Oct 24th version Outstanding issue: implications of carrying attributes and credentials within the same protocol or within different protocols Outstanding issue: Id vs URL issued raised by Tom Scavo: http://www.ogf.org/pipermail/ogsa-authz-wg/2006-November/000242.html Doc should then be ready for WG final call and progression to AD * Protocol Doc Updates Described 3 protocol 1) PEP-Context Handler: no profile proposed. Maybe the same as protocol #3 if credentials can be carried in same field as attributes in the protocol. 2) Context Handler-CVS: WS-Trust profile: http://forge.gridforum.org/sf/go/doc9011?nav=1 3) Context Handler-PDP: proposal XACML request/response protocol proposed: the current profile, available from http://forge.gridforum.org/sf/go/doc13681?nav=1 in which the XACML request context is transported to the PDP in a SAML request message. Apparently this OASIS mechanism has been deprecated because it was (wrongly) thought that no-one was using it. We thus may need to reconsider this protocol and use a different wrapper to carry the XACML contexts. * Takuya Mori presentation on NAREGI Authz Service and NAREGI XACML profile Slides: http://forge.gridforum.org/sf/go/doc14166?nav=1 SAML 2.0 and XACML 2.0 based Uses GT authz framework Profile between Authz service client (in GT4) and Authz CVS Handles VOMS AC's and passes to Authz service Presented mapping of attributes from X.509 EEC/VOMS AC into XACML Resource Attribute Filtering Mechanism (RAFM) - Reference properties, XACML profile has Subject, Resource and Action attributes There is an issue as to how a resource's attributes are obtained by the PEP. If the user submits them to the PEP there is a potential trust issue here, and the attributes will need to validated by the CVS. If the PEP obtains them itself from a local store this is not an issue. * VOMS profile Discussed on Oct 16 telecon - minutes on list Meaning of the primary type must be explicit rather than implicit (as currently done via sequence) Awaiting response from VOMS group Valerio: What we haven't understood so far is why an explicit primary attribute is needed rather then an implicit one and what needs an eventual change in VOMS AC format would address. [Discussion continued on ogsa-authz email list] * Attribute Retrieval Protocol Added as last meeting OASIS profile for SAML - Tom Scavo author * Von Welch resignation as WG chair Those who are interesting in replacing Von should send email to David * Other business Tom Scavo: Do we need mechanism to bind SAML to X.509 (equivalent to VOMS)? (https://spaces.internet2.edu/display/GS/X509BindingSAML) David: 2005 X.509 has specification for binding XML to X.509, but doesn't specify XML content Tom Scavo to investigate how these relate. David: VOMS is providing a standard SAML protocol interface for picking up VOMS attributes. A beta is supposed to be ready by April 2007 (Valerio: That's correct David. The protocol is that in SAML V2.0 Profiles for X.509 Subject as agreed. We are about to work on the implementation of the protocol and we will eventually inform Tom and the authors about any issue we may have. Hope it won't be too late by that time but we couldn't make it before.) (Later in email Tom directs to http://www.oasis-open.org/committees/download.php/21568/ sstc-saml2-profiles-deploy-x509-draft-01.pdf)

2 2