January 2008 - ogsa-authz-wg

Implementations
by David Chadwick 05 Apr '08

05 Apr '08

Dear WG I would like to draw up a table of implementations of the 3 protocol profile docs that we have published (XACML, WS-Trust and SAML AA). The information that would be useful for the group is Profile being implemented: Organisation doing the implementation: Contact details: Short description: (the latter to contain such things as status of implementation, any interworking carried out, where software might be obtained etc. Whatever you feel is appropriate for the WG) 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 *****************************************************************

7 36

VO SAML Attribute Profile
by Valerio Venturi 15 Feb '08

15 Feb '08

Hi, following (with an embarassing delay) Tom Scavo's mail on defining a SAML profile for VOMS attribute, I'm posting a document Krzysztof Benedyczak and I was editing with initial thoughts on the matter. I'm not uploading it to gridforge until it's more complete than it is now. If the issue raise interest and we manage to agree on a document, we may ask Blair and DavidG about a possible recommendification, though I think that not being in the current charter make it difficult. Let's see, the discussion is anyway usefull. I profit to wish everybody a nice holiday. Valerio

7 33

checkpointing the discussion on VO attributes
by Valerio Venturi 07 Feb '08

07 Feb '08

Hi, I'll try to checkpoint the discussion had so far. As Krzysztof is planning to serve more than one VO with the same service, we cannot have a one to one relationship between entityIDs and VOs, this imply the need of having a VO attribute. Which was also more or less David's concern, an authority being able to assert whatever it wants. If we go wiht this, the VO attribute stays. We have two proposal so far. Tom suggested to use the MACE-Dir eduPersonScopedAffiliation attribute <saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" FriendlyName="eduPersonScopedAffiliation"> <saml:AttributeValue xsi:type="xs:string">member@voName </saml:AttributeValue> </saml:Attribute> while in our first draft Krzysztof and I suggested the use of a specific <saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="uri_to_define" FriendlyName="vo" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"> <saml:AttributeValue xsi:type="xsd:string"> voName </saml:AttributeValue> </saml:Attribute> Let's try to agree on one. There were concerns about Tom's proposal to use Grouper to express groups, specifically about the contents being an URN. Anyway, the specification doesn't mandate them to be URN, it recommends to use URIs is uniqueness is to eb achieved. Other concerns with using this? Still we have no suggestions for expressing roles, apart from the initial (but I have made the group syntax homogeneous with the above) <saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="uri_to_define" FriendlyName="role" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"> <saml:AttributeValue xsi:type="xsd:string"> VO-Admin@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@vo:group:subgroup </saml:AttributeValue> </saml:Attribute> that seems to receive more favor than the one with the scope attributes. What problems can you see with that? Valerio

7 22

Fwd: [security-services] Public Review of SAML Specifications
by Tom Scavo 04 Feb '08

04 Feb '08

FYI OASIS has announced a 60-day public review period for a group of five specifications being considered by the SSTC. Three of those specifications involve attributes. Of particular interest to this group is the SAML V2.0 Deployment Profiles for X.509 Subjects, which underlies the OGSA Attribute Exchange Profile (a new version of which Valerio uploaded to gridforge this morning). Also of interest is the SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems, which supports the same use case as the SAML V2.0 Deployment Profiles for X.509 Subjects but has a different emphasis. Of course your comments are encouraged. Note that the OASIS TC process requires that all comments be given full consideration before the specification can proceed in committee. Thanks, Tom Scavo NCSA ---------- Forwarded message ---------- From: Mary McRae <mary.mcrae(a)oasis-open.org> Date: Dec 10, 2007 11:30 PM Subject: [security-services] Public Review of SAML Specifications To: members(a)lists.oasis-open.org, tc-announce(a)lists.oasis-open.org Cc: OASIS SSTC <security-services(a)lists.oasis-open.org> To OASIS members, Public Announce Lists: The OASIS Security Services (SAML) TC has recently approved the following specifications as Committee Drafts and approved each of the following five (5) specifications for public review: 1. SAMLv2.0 HTTP POST "SimpleSign" Binding 2. Identity Provider Discovery Service Protocol and Profile 3. SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems 4. SAML V2.0 Deployment Profiles for X.509 Subjects 5. SAML V2.0 LDAP/X.500 Attribute Profile The public review starts today, 11 December 2007, and ends 9 February 2008. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. Please feel free to distribute this announcement within your organization and to other appropriate mail lists. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=security. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/security-services-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: 1. SAMLv2.0 HTTP POST "SimpleSign" Binding Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.html 2. Identity Provider Discovery Service Protocol and Profile Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… dt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… df HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… tml Schema: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… df 3. SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.html 4. SAML V2.0 Deployment Profiles for X.509 Subjects Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.html Schema: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… .xsd 5. SAML V2.0 LDAP/X.500 Attribute Profile Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. html OASIS and the Security Services (SAML) TC welcome your comments. --------------------------------------------------- Mary P McRae Manager of TC Administration, OASIS email: mary.mcrae(a)oasis-open.org web: www.oasis-open.org --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

1 1

comments on "OGSA Attribute Exchange Profile Version 1.2"
by Blair Dillaway 21 Jan '08

21 Jan '08

A few comments and questions on this draft: 1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document. 2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement. If it changes, I think you should justify the difference in the two specs. 3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction. 4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used. You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter. 5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms. Within grids, I would have thought people would want a message security interop profile all implementers would agree to support. Regards, Blair

4 7

comments on "Use of WS-TRUST and SAML to access a CVS" and "Use of XACML Request Context to Obtain an Authorisation Decision"
by Blair Dillaway 10 Jan '08

10 Jan '08

Some comment and questions on the latest drafts. My comments use the below numbers to reference each spec [1] "Use of XACML Request Context to Obtain an Authorisation Decision, 31 Oct 2007" [2] "Use of WS-TRUST and SAML to access a CVS, 31 Oct 2007" Comments on [1]: 1) The definition of a credential in section 4.2.2 and in [2] are different. I prefer this definition. In the credential table, you could use "wsse:Kerberosv5ST" as the Kerb token value type per the WS-Security Kerberos profile, though perhaps you don't want to drag in yet another namespace. I believe you'll have to define an identifier for proxy certs and SAML assertions. 2) The obligation encoding seems okay. I don't have a good feel for whether the defined obligation IDs are the right ones to standardize and require all implementers to handle. It would be good to hear from others who have been building XACML-based solutions. 3) Should this spec define an interop security profile for authentication, integrity, and confidentiality of messages between the PEP and PDP? The SAML standard defines some options but I don't believe anything is mandatory. Seems like it should at least be discussed in the security considerations section. Comments on [2]: 1) The WS-Trust spec referenced is obsolete. I suggest you reference the OASIS standard WS-Trust 1.3, 19 March 2007. http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html. I don't believe the change has a significant impact on the design in this spec, though it may need a few minor tweaks. 2) In section 3 it says "The PEP may provide any arbitrary set of credentials, e.g. member of university X, member of grid project Y, registered doctor, certified engineer etc. issued by any arbitrary set of attribute authorities (AAs) or credential issuers; as well as any arbitrary set of references (meta-information) to credential issuing services." I would argue that you are describing 'claims' asserted by some set of issuing authorities, not credential types. In any event, this seems to contradict spec [1] which says in 4.2.2 "If a bag of unvalidated credentials are passed by the PEP to the PDP, these credentials may be in a variety of formats e.g. X.509 public key certificate, X.509 attribute certificate, X.509 proxy certificate, VOMS attribute certificate embedded in a proxy certificate, Kerberos Ticket, Shibboleth attribute, proprietary credentials etc." If the definition in this spec is what was intended, then it seems to imply the PEP or PDP would be responsible for validating signatures/integrity of input security tokens (credentials as defined in [1]); decoding the token and re-encoding the information into a set of SAML claims and associated issuing authority(s). This spec makes sense if I make this interpretation, I'm just uncertain if that's what was intended. Perhaps some clarifying text could be added? 3) In 3.1 "the CVS returns a set of valid attributes to the PEP, that are in the correct format for passing to the PDP". I would suggest you change this to "... for passing to the XACML PDP" and note in the introduction that this spec assumes an authZ environment with an XACML PDP. That would make it consistent with the statement in 3.2 that "..the CVS described in this document is a source of attribute values that are ready to be passed to an XACML conformant PDP." 4) From section 4 (and 5 & 6), definition of supported SAML assertions, #4 says "The NameID option MUST be used, and the Format SHOULD be X.509 subject name.". From this I take it the intent is to restrict this profile to the use of authentication infrastructures which identify principals using X.509 DNs? That should probably be clarified in the introductory material. X.509-based grid authN is certainly the most common case today, but is problematic if using non-X.509 tokens such as Kerberos. Related to '2' above, the description here makes sense if one assumes the PEP or PDP re-encode security token information as SAML assertions. I'm unclear on the intended processing model if one is allowed to pass unvalidated security tokens. It seems that the requestor would need to parse the tokens to fill in the mandatory issuer information in the request, which would adds complexity to the PEP or PDP. 5) Should this spec define an interop security profile for authentication, integrity, and confidentiality when using the defined WS-Trust profile? Seems like it should at least be discussed in the security considerations section. Regards, Blair

1 0