March 2009 - pgi-wg - lists.ogf.org

OGF PGI - Security Strawman
by Etienne URBAH 16 Apr '09

16 Apr '09

To All, I thank Duane MERRIL for his 'Profile on Secure Communication' strawman. But, since today's mail of Vincenzo CIASCHINI asserting interoperability between recent versions of OpenSSL and GSI, I do NOT think that communication layers are the main isue blocking interoperability. I propose that instead focusing on communication services, we focus on security data defined, on security data transported, and on the interpretation of security data by AUTHN/AUTHZ services. So, I propose to criticize following assertions : 1) Grid Users and Certificate Authorities ----------------------------------------- 1.1) Each grid User is authenticated by a legal body (recognized by a government). 1.2) This legal body uses a Certificate Authority to grant a (long lived) X509 certificate to the grid User. 1.3) Each Certificate Authority is itself or is authenticated by a self-signed Root Certificate Authority. 1.4) All such Root Certificate Authorities trust each other and cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management Authorities). 1.5) These 3 Policy Management Authorities trust each other and cooperate within IGTF. 1.6) IGTF distributes the list of CA Certificates to be trusted. 1.7) Each grid Site providing grid Services to grid Users MUST install this list of CA Certificates and keep it up to date. 1.8) Using its X509 certificate, each grid User can create at any time a (short lived) X509 proxy with permits impersonation / delegation during a short period. 2) Virtual Organizations ------------------------- 2.1) A Virtual Organization (VO) groups grid Users with common goals. A VO is NOT a legal body, can NOT be a Certificate Authority, and can NOT issue X509 certificates. 2.2) Inside DEISA, a Virtual Community also groups grid Users with common goals. The relationships between Virtual Communities and Virtual Organizations has to be precised by Morris RIEDEL. 2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), which grants him access rights to grid Storage and Computing Ressources. 2.4) Access rights are granted by VOs to grid Users through either : 2.4.1) VOMS extensions of X509 proxies (this makes a VOMS proxy) 2.4.2) SAML assertions 3) Grid Services : Information, AUTHN, AUTHZ ---------------------------------------------- 3.1) Each grid Infrastucture provides an Information Service, with describes the Infrastructure according the the GLUE2 schema. 3.2) Each grid User can query this Information Service anonymously in order to know which security protocol he has to use to submit requests to grid Services. 3.3) Each grid User can directly access data hosted by grid Storage Services. For Authentication, the grid User can present the public part of his X509 certificate or X509 proxy. For Authorization, the grid User can present : 3.3.1) the public part of his VOMS proxy, or 3.3.2) a bag of SAML assertions. 3.4) Each grid User can submit Jobs to grid Computing Services. If such a Job needs access to data hosted by grid Storage Services, then the grid User must provide a delegation token. This delegation token can be : 3.4.1) a full VOMS proxy, or 3.4.2) a bag of SAML assertions. 4) Consequences for Interoperability ------------------------------------- 4.1) X509 proxies MUST fully comply to RFC 3820. 4.2) VOMS services, which deliver X509 proxies with VOMS extensions, MUST fully comply to RFC 3820. 4.3) The authentication library used by grid Services MUST fully comply to RFC 3820 (for example a recent version of OpenSLL), so that it can accept as well X509 certificates as X509 proxies. 4.4) Each grid Site providing grid Services to grid Users MUST install files describing VOMS authorizations and other authorizations, and keep them up to date. 4.5) The semantics of Authorization tokens MUST be the same for all grid Infrastructures : 4.5.1) VOMS extensions 4.5.2) Restriction attributes 4.6) The Information Service of each grid Infrastructure MUST describe, for each grid Service, which Authorization tokens this Service understands (potentially several) : 4.6.1) VOMS extensions 4.6.2) X509 restriction attributes 4.6.3) SAML assertions 4.7) For SAML assertions, the Information Service of each grid Infrastructure MUST describe, for each grid Service, how they are transported : 4.7.1) As attributes of X509 proxies 4.7.2) Inside a SOAP header Unfinished ... Best regards. ---------------------------------- Etienne URBAH IN2P3 - LAL Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Mob: +33 6 22 30 53 27 Skype: etienne.urbah mailto:urbah@lal.in2p3.fr ----------------------------------

12 43

***SPAM*** Sec: Discussion about agrreement of attributes
by m.riedel＠fz-juelich.de 16 Apr '09

16 Apr '09

Hi PGI team, as promised to Etienne and as being part of our security topics is also a refinement of used attributes in our interops reaching an agreement between our infrastructures. Clearly we have the base given by the VOMS AC-defined FQANs - however the structure should be a discussion as well. However, this seems to be very 'EGEE' focussed. I have four topics for discussion in this context: (1) Considering interops between Grids we should provide an attribute that basically indicates if a user may 'belong' to a specific production Grid (e.g.DEISA, EGEE, NAREGI). Currently, VOs seem to be the top hierarchy - however I think it would be good to bring up attributes for that to distinguish at policy level which elements of policies should be used, e.g. users of TeraGrid in DEISA have a special policy, etc. (2) DEISA view, addressing the question of Etienne slightly), taking my talk of OGF25 into account if you would like to know more: Talk about how users can involved with DEISA: http://www.ogf.org/OGF25/materials/1557/2009-03-02_DEISA_DECI_Riedel.pdf Thus DEISA has basically two top-level attributes: DECI projects (that can be maybe categorized in scientifically defined VOs building different groups for each DECI project) and Virtual Communities (that are basically on the same level as DECI projects but completely seperated from it). Given that the virtual community is maybe part of a larger defined scientific group (e.g. astro), I see that also virtual communities can be defined as groups in parallel to DECI projects (so groups) - however, virtual communities have a kind of 'prioritized' access and thus there should be maybe a better differentiation avoiding going to deep in attribute hierarchies. (3) Agreements between attribute differences between job management and data management (4) What do others think about the FQANs and its use - some critics or missing links I maybe have not talked about yet? Take care, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel(a)fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ----- Original Message ----- From: m.riedel(a)fz-juelich.de Date: Monday, March 30, 2009 10:48 am Subject: [Pgi-wg] MWSG Meeting Slides (Drafts) > Hi PGI team, > > I received some contributions already and setup a first draft > for the slides I will present tomorrow! > > They are in GridForge - so please comment the whole day today: > > http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/do… > > > The discussions about attributes and constraints I will start just > after the coffee break here. ;-) > > Best regards from Zuerich, > Morris > > > > > > ------------------------------------------------------------------- > ------------------------------------------------------------------- > Forschungszentrum Juelich GmbH > 52425 Juelich > > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, > Dr. Sebastian M. Schmidt > ------------------------------------------------------------------- > ------------------------------------------------------------------- > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

MWSG Meeting Slides (Drafts)
by m.riedel＠fz-juelich.de 01 Apr '09

01 Apr '09

Hi PGI team, I received some contributions already and setup a first draft for the slides I will present tomorrow! They are in GridForge - so please comment the whole day today: http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/do… The discussions about attributes and constraints I will start just after the coffee break here. ;-) Best regards from Zuerich, Morris ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

5 4

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by Duane Merrill 31 Mar '09

31 Mar '09

On Tue, Mar 31, 2009 at 12:47 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > > Now VOMS offers a SAML interface. Assuming the protocol remains the > same (i.e., a self-query to the VOMS server), then that leads quite > naturally to SAML tokens bound to proxy certificates. That's the path > of least resistance for grids already invested in VOMS. Your PGI peers seem to disagree with you. They are of the opinion that Proxy+VomsACs is the path of least resistance (and not Proxy+VomsSAML). The SAML considerations for the PGI profile(s) were primarily considered for PGI-profiling simply b/c they are a bridge-of-least-resistance to support Unicore. > > Duane, is your spec open for public comments? > It was just a "strawman" doc: input material that was put together to foster discussion of actual technical details for interop. So technically it's not open for public comments in the strict OGF document-process sense (and never will be in that form), but, in the general case, it was written explicitly to foster discussion. Cheers, Duane

1 0

Slides from MWSG Meeting Zurich
by m.riedel＠fz-juelich.de 31 Mar '09

31 Mar '09

Hi PGI team, just4info: the slides we agreed upon/discussed are online at: http://indico.cern.ch/getFile.py/access?contribId=9&sessionId=3&resId=0&mat… I'm gonna present them and ask for comments in a few minutes... Take care, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel(a)fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by Duane Merrill 31 Mar '09

31 Mar '09

> > Unless I'm missing something, this spec misses the important use case > where a holder-of-key SAML token is carried in a proxy certificate > (completely analogous to the typical VOMS AC case). > SAML tokens embedded within proxy certificates isn't one of the "common denominators" identified by the pgi-wg as an "authz plumbing" (to borrow Morris' phrasing). And if the point of the PGI-WG is to move forward in a unified direction with SAML instead of documenting the mish-mash myriad of ways for expressing the same thing that exist now, then 2.0 would be the place to hang your hat. -Duane

1 0

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by weizhong qiang 30 Mar '09

30 Mar '09

hi, On Tue, Mar 31, 2009 at 12:15 AM, Tom Scavo <trscavo(a)gmail.com> wrote: > On Mon, Mar 30, 2009 at 1:16 PM, weizhong qiang <weizhongqiang(a)gmail.com> > wrote: > > > > On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > >> > >> On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang > >> <weizhongqiang(a)gmail.com> wrote: > >> > > >> > 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate> > >> > element, but it probably be better to just contain a <ds:KeyValue>, > >> > since > >> > the certificates chain of the "subject" is already supposed to be > >> > verified > >> > by the third-party authority (in this case, it is voms saml service), > >> > and > >> > then this public key is used to sign the soap message afterwards. > >> > >> I don't see what the certificate chain has to do with the use of the > >> <ds:X509Certificate> element in this case. The latter requires the > >> presenter to prove possession of the private key corresponding to the > >> public key bound to the certificate. What does that have to do with > >> the presented certificate chain? > > > > two types of verification here: > > 1. verify that "possession of the private key corresponding to the public > > key bound to the certificate" > > Which is required for holder-of-key subject confirmation, yes. > > > 2. verify that "possession of the private key corresponding to the public > > key bound to the certificate" + verify that the certificate is signed by > > trusted authority (in this case verification of certificates chain is > > needed.) > > > > What I meant is for SAML Token profile, step 2 is not needed. > > Okay. > > >> > <ds:KeyValue> is also convinient for proxy certificate, in my opinion. > >> > >> I don't see what <ds:KeyValue> gains you in this case, but I may be > >> missing something. Unless you can provide a good reason for using > >> <ds:KeyValue>, I recommend <ds:X509SubjectName> or <ds:X509SKI>, in > >> that order. The <ds:X509SubjectName> element is simplest for proxy > >> certificates, I think. It is equivalent to the subject confirmation > >> implied in VOMS proxies, in fact. > > > > Probably <ds:KeyValue> can not gain more than <ds:X509Certificate> > (formerly > > I supposed the <ds:KeyValue> should be standarlized) . But by using > > <ds:X509SubjectName>, what is the way to get the public key, which is > > required when verifying the signature to SOAP message. > > Suppose that the presenter authenticates to the relying party Here in my understanding the presenter (requester) does not need to authenticate to relying-party (resource) by using its credential, because the presenter has already authenticated to IdP (STS, secure token service, or whatever other names), and the authentication result (a SAML Token with <saml:SubjectConfirmation> inside) is supposed to be trusted by relying party (if there is trust relationship between IdP and resource). So the preseter is not supposed to use it credential to authenticate against Resource once more (here I am talking in the contex if SOAP message is protected by SAML Token, by using the presenter's private key to make signature for SOAP message). Weizhong Qiang > using a > proxy credential signed by the same X.509 end-entity credential used > to request the assertion from the IdP in the first place. > (Authentication can be by transport-level or message-level as you > mentioned earlier.) By proving possession of the private key > associated with the proxy, the presenter has proven that it is the > subject given by the subject DN in the end-entity certificate of the > presented proxy certificate chain. Thus any holder-of-key SAML > assertion containing that DN is automatically confirmed. > > >> In any event, I should point out that the SAML V2.0 Holder-of-Key > >> Assertion Profile is now in its formal Public Review period, and it > >> does not profile <ds:KeyValue>, so if you think that's an error of > >> omission, it would be good if you could submit a public comment to > >> that effect. > >> > >> > http://lists.oasis-open.org/archives/security-services/200903/msg00062.html > > > > Is any of the draft you mentioned in this link supposed to update/replace > > the WS-Security SAML Token 1.1 profile? > > No, the WSS Technical Committee is closed so I don't anticipate any > changes to be made to the WSS token profiles. > > Tom >

1 0

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by Duane Merrill 30 Mar '09

30 Mar '09

https://forge.gridforum.org/sf/go/doc15575?nav=1 -Duane On Mon, Mar 30, 2009 at 5:41 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > Duane, can you post a pointer please? Thanks. > > On Mon, Mar 30, 2009 at 5:37 PM, Duane Merrill <dgm4d(a)virginia.edu> wrote: > > BTW, the original PGI Strawman contains some considerations for what > exactly > > what you are discussing, regarding a SOAP-SAML-attribute profile. > > > > -Duane > > > > > > > > 2009/3/30 weizhong qiang <weizhongqiang(a)gmail.com> > >> > >> hi, > >> > >> On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > >>> > >>> On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang > >>> <weizhongqiang(a)gmail.com> wrote: > >>> > > >>> > For a SAML Token which is compliant to SAML V1.1... > >>> > > >>> > For a SAML Token which is compliant to SAML V2.0... > >>> > >>> It should be noted that these examples from the WSS SAML Token Profile > >>> are not normative. Indeed, the SAML V2.0 token is not even > >>> schema-valid. > >> > >> Thanks. I did not know that. But I also thought this part of > specification > >> in WS-Security is not so clearly defined. > >> > >>> > >>> > 1. The signature for <saml:Reponse> could also be necessary, even > >>> > though the > >>> > integrity is guaranteed by TLS. > >>> > >>> That's unlikely, I think. The Response is consumed by the requester > >>> (it does not appear in the SOAP header) so there's really no need > >>> (that I can see) to sign the Response if the request is made over > >>> mutually authenticated TLS. > >>> > >>> > 2. xml attribute xsi:type="saml2:KeyInfoConfirmationDataType" could > be > >>> > necessary for <saml2:SubjectConfirmationData/> > >>> > >>> As I recall, that type declaration is optional, but yes, its use is > >>> recommended. > >>> > >>> > 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate> > >>> > element, but it probably be better to just contain a <ds:KeyValue>, > >>> > since > >>> > the certificates chain of the "subject" is already supposed to be > >>> > verified > >>> > by the third-party authority (in this case, it is voms saml service), > >>> > and > >>> > then this public key is used to sign the soap message afterwards. > >>> > >>> I don't see what the certificate chain has to do with the use of the > >>> <ds:X509Certificate> element in this case. The latter requires the > >>> presenter to prove possession of the private key corresponding to the > >>> public key bound to the certificate. What does that have to do with > >>> the presented certificate chain? > >> > >> two types of verification here: > >> 1. verify that "possession of the private key corresponding to the > public > >> key bound to the certificate" > >> 2. verify that "possession of the private key corresponding to the > public > >> key bound to the certificate" + verify that the certificate is signed by > >> trusted authority (in this case verification of certificates chain is > >> needed.) > >> > >> What I meant is for SAML Token profile, step 2 is not needed. > >> > >>> > >>> > For SOAP > >>> > message verification on the rely-party side, the rely-party do not > need > >>> > to > >>> > verify the certificates chain of "subject". > >>> > >>> I'm not sure I follow you. How does the presenter of the SOAP request > >>> (with SAML token in the SOAP header) authenticate to the SOAP > >>> responder? > >> > >> "authentication" here could not be accurate. > >> SOAP presentor authenticates (via TLS, or SOAP message authentication by > >> using X.509 token) to 3-party authority (trusted by rely-party), and > gets > >> back SAML Token (with the presentor's public key, or certificate inside > as > >> part of <saml:SubjectConfirmation>); Then uses its' own private key to > sign > >> soap message; Afterwards rely-party can verify the signature to SOAP > message > >> (simple verification is needed, just verify that the private key which > >> signes the SOAP message corresponds to the public key in the > >> <saml:SubjectConfirmation>), as well as verify the signature to > >> <saml:Assertion> (simple verification + verifying the certificate in > >> <ds:Signature> is trusted). > >> > >> > >>> > >>> > <ds:KeyValue> is also convinient for proxy certificate, in my > opinion. > >>> > >>> I don't see what <ds:KeyValue> gains you in this case, but I may be > >>> missing something. Unless you can provide a good reason for using > >>> <ds:KeyValue>, I recommend <ds:X509SubjectName> or <ds:X509SKI>, in > >>> that order. The <ds:X509SubjectName> element is simplest for proxy > >>> certificates, I think. It is equivalent to the subject confirmation > >>> implied in VOMS proxies, in fact. > >> > >> Probably <ds:KeyValue> can not gain more than <ds:X509Certificate> > >> (formerly I supposed the <ds:KeyValue> should be standarlized) . But by > >> using <ds:X509SubjectName>, what is the way to get the public key, > which is > >> required when verifying the signature to SOAP message. > >> > >>> > >>> In any event, I should point out that the SAML V2.0 Holder-of-Key > >>> Assertion Profile is now in its formal Public Review period, and it > >>> does not profile <ds:KeyValue>, so if you think that's an error of > >>> omission, it would be good if you could submit a public comment to > >>> that effect. > >>> > >>> > >>> > http://lists.oasis-open.org/archives/security-services/200903/msg00062.html > >> > >> Is any of the draft you mentioned in this link supposed to > update/replace > >> the WS-Security SAML Token 1.1 profile? > >> > >> > >> Weizhong Qiang > >> > >> > >>> > >>> > >>> > 4. Use <saml:Statement> instead of <saml:AttributeStatement>. > >>> > >>> Why? The <saml:Statement> element is abstract so that would require a > >>> type. What type do you recommend (if not > >>> saml:AttributeStatementType)? > >>> > >>> Tom > >>> > >>> > On Mon, Mar 30, 2009 at 5:00 PM, Tom Scavo <trscavo(a)gmail.com> > wrote: > >>> >> > >>> >> Hi Weizhong, > >>> >> > >>> >> Can you outline why you think the VOMS SAML assertion is not > >>> >> compatible with the WSS SAML Token Profile? > >>> >> > >>> >> Thanks, > >>> >> Tom > >>> >> > >>> >> PS. The comments quoted below mostly refer to a VOMS SAML assertion > >>> >> bound to an X.509 proxy certificate (but the requirements are not > the > >>> >> same as a VOMS SAML assertion bound to SOAP header). > >>> >> > >>> >> On Mon, Mar 30, 2009 at 10:25 AM, weizhong qiang > >>> >> <weizhongqiang(a)gmail.com> wrote: > >>> >> > hi voms folks, all, > >>> >> > The current voms SAML assertion is not compatible with WS-Security > >>> >> > SAML > >>> >> > Token profile. I would ask is there any plan to change it to make > it > >>> >> > be > >>> >> > compatible? I ask this because I think if so, the SAML assertion > can > >>> >> > be > >>> >> > used > >>> >> > for SOAP message layer authentication, other than just including > >>> >> > SAML > >>> >> > attribute assertion. > >>> >> > > >>> >> > > >>> >> > Thanks > >>> >> > Weizhong Qiang > >>> >> > > >>> >> > > >>> >> > On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo(a)gmail.com> > >>> >> > wrote: > >>> >> >> > >>> >> >> Thanks to Benjamin for posting this VOMS-SAML response to > gt-user. > >>> >> >> A > >>> >> >> critique (of the SAML, not Benjamin :) follows. > >>> >> >> > >>> >> >> - Note that the output is a <samlp:Response> element, not a > >>> >> >> <saml:Assertion> element. This is wrong. The requester must > >>> >> >> consume > >>> >> >> the response. Not sure why this isn't happening. > >>> >> >> > >>> >> >> - The value of the <saml:Issuer> element in the response is a DN > >>> >> >> but > >>> >> >> the Format XML attribute is missing. This is a bug. The default > >>> >> >> Format is "unspecified" but clearly this is not. > >>> >> >> > >>> >> >> - Second-level status codes are desirable so they can be echoed > on > >>> >> >> the > >>> >> >> command line (if any). > >>> >> >> > >>> >> >> - Same comment about the <saml:Issuer> element in the assertion. > >>> >> >> > >>> >> >> - The use of SAML metadata requires that the Format on the > >>> >> >> <saml:Issuer> element be "entity" but clearly it is not. Thus > the > >>> >> >> use > >>> >> >> of SAML metadata by the relying party is precluded. > >>> >> >> > >>> >> >> - Don't know if Shibboleth/OpenSAML can verify the signature > (which > >>> >> >> is > >>> >> >> tricky business). This is a future experiment that needs to be > >>> >> >> done. > >>> >> >> > >>> >> >> - The <saml:SubjectConfirmation> element contains a > >>> >> >> <ds:X509Certificate> element, which precludes the binding of this > >>> >> >> holder-of-key assertion to a proxy certificate. This is a bug. > >>> >> >> Use a > >>> >> >> <ds:X509SubjectName> element instead (which causes the NameID > >>> >> >> itself > >>> >> >> to be redundant). > >>> >> >> > >>> >> >> - If the assertion is bound to a proxy certificate, the NotBefore > >>> >> >> and > >>> >> >> NotOnOrAfter attributes are redundant and superfluous. In fact, > >>> >> >> they > >>> >> >> may be wrong since they must agree with the NotBefore and > >>> >> >> NotOnOrAfter > >>> >> >> fields of the proxy. > >>> >> >> > >>> >> >> - Since the client authenticated directly to the server, a > >>> >> >> <saml:AuthnStatement> is desirable (not required, but potentially > >>> >> >> useful at the relying party). > >>> >> >> > >>> >> >> - The NameFormat XML attribute on the <saml:Attribute> element > >>> >> >> should > >>> >> >> be "uri" not "unspecified". > >>> >> >> > >>> >> >> - The "xsi:" prefix on the <saml:AttributeValue> element is > >>> >> >> undefined. > >>> >> >> This is a bug. > >>> >> >> > >>> >> >> - The <saml:AttributeValue> elements do not conform to the XACML > >>> >> >> Attribute Profile (actually, I don't think the attributes conform > >>> >> >> to > >>> >> >> *any* SAML V2.0 attribute profile). > >>> >> >> > >>> >> >> Hope this helps, > >>> >> >> Tom > >>> >> >> > >>> >> >> ---------- Forwarded message ---------- > >>> >> >> From: Benjamin Henne <henne(a)rvs.uni-hannover.de> > >>> >> >> Date: Wed, Feb 4, 2009 at 1:59 AM > >>> >> >> Subject: Re: [gt-user] SAML based VOMS Server > >>> >> >> To: Tom Scavo <trscavo(a)gmail.com> > >>> >> >> Cc: GT User <gt-user(a)globus.org> > >>> >> >> > >>> >> >> > >>> >> >> <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" > >>> >> >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > >>> >> >> ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6" > >>> >> >> InResponseTo="_qwertyuiopasdfghjklzxcvbn" > >>> >> >> IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0"> > >>> >> >> <saml:Issuer > >>> >> >> > >>> >> >> > >>> >> >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN= > voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >>> >> >> <Status> > >>> >> >> <StatusCode > Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > >>> >> >> </Status> > >>> >> >> <saml:Assertion > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > >>> >> >> ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac" > >>> >> >> IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0"> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> <saml:Issuer>CN=voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >>> >> >> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >>> >> >> <ds:SignedInfo> > >>> >> >> <ds:CanonicalizationMethod > >>> >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >>> >> >> <ds:SignatureMethod > >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > >>> >> >> <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"> > >>> >> >> <ds:Transforms> > >>> >> >> <ds:Transform > >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature > "/> > >>> >> >> <ds:Transform > >>> >> >> > >>> >> >> > >>> >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n# > "><ec:InclusiveNamespaces > >>> >> >> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" > PrefixList="ds > >>> >> >> saml > >>> >> >> xs"/></ds:Transform> > >>> >> >> </ds:Transforms> > >>> >> >> <ds:DigestMethod > >>> >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > >>> >> >> <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue> > >>> >> >> </ds:Reference> > >>> >> >> </ds:SignedInfo> > >>> >> >> <ds:SignatureValue> > >>> >> >> ... > >>> >> >> </ds:SignatureValue> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature> > >>> >> >> <saml:Subject> > >>> >> >> <saml:NameID > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin > >>> >> >> Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID> > >>> >> >> <saml:SubjectConfirmation > >>> >> >> Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> > >>> >> >> <saml:SubjectConfirmationData> > >>> >> >> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig# > "> > >>> >> >> <ds:X509Data> > >>> >> >> <ds:X509Certificate>...</ds:X509Certificate> > >>> >> >> </ds:X509Data> > >>> >> >> </ds:KeyInfo> > >>> >> >> </saml:SubjectConfirmationData> > >>> >> >> </saml:SubjectConfirmation> > >>> >> >> </saml:Subject> > >>> >> >> <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z" > >>> >> >> NotOnOrAfter="2008-10-17T06:03:57.920Z"/> > >>> >> >> <saml:AttributeStatement> > >>> >> >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles" > >>> >> >> > >>> >> >> > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">staff@ > /RVS/research/SAML</saml:AttributeValue> > >>> >> >> </saml:Attribute> > >>> >> >> <saml:Attribute Name="nationality" > >>> >> >> > >>> >> >> > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">German</saml:AttributeValue> > >>> >> >> </saml:Attribute> > >>> >> >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group" > >>> >> >> > >>> >> >> > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">/RVS/education</saml:AttributeValue> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">/RVS</saml:AttributeValue> > >>> >> >> <saml:AttributeValue > >>> >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >>> >> >> xsi:type="xs:string">/RVS/research</saml:AttributeValue> > >>> >> >> </saml:Attribute> > >>> >> >> </saml:AttributeStatement> > >>> >> >> </saml:Assertion> > >>> >> >> </Response> > >>> >> > > >>> >> > > >>> > > >>> > > >> > >> > >> _______________________________________________ > >> Pgi-wg mailing list > >> Pgi-wg(a)ogf.org > >> http://www.ogf.org/mailman/listinfo/pgi-wg > >> > > > > >

1 0

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by weizhong qiang 30 Mar '09

30 Mar '09

hi, On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang > <weizhongqiang(a)gmail.com> wrote: > > > > For a SAML Token which is compliant to SAML V1.1... > > > > For a SAML Token which is compliant to SAML V2.0... > > It should be noted that these examples from the WSS SAML Token Profile > are not normative. Indeed, the SAML V2.0 token is not even > schema-valid. Thanks. I did not know that. But I also thought this part of specification in WS-Security is not so clearly defined. > > > > 1. The signature for <saml:Reponse> could also be necessary, even though > the > > integrity is guaranteed by TLS. > > That's unlikely, I think. The Response is consumed by the requester > (it does not appear in the SOAP header) so there's really no need > (that I can see) to sign the Response if the request is made over > mutually authenticated TLS. > > > 2. xml attribute xsi:type="saml2:KeyInfoConfirmationDataType" could be > > necessary for <saml2:SubjectConfirmationData/> > > As I recall, that type declaration is optional, but yes, its use is > recommended. > > > 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate> > > element, but it probably be better to just contain a <ds:KeyValue>, since > > the certificates chain of the "subject" is already supposed to be > verified > > by the third-party authority (in this case, it is voms saml service), and > > then this public key is used to sign the soap message afterwards. > > I don't see what the certificate chain has to do with the use of the > <ds:X509Certificate> element in this case. The latter requires the > presenter to prove possession of the private key corresponding to the > public key bound to the certificate. What does that have to do with > the presented certificate chain? two types of verification here: 1. verify that "possession of the private key corresponding to the public key bound to the certificate" 2. verify that "possession of the private key corresponding to the public key bound to the certificate" + verify that the certificate is signed by trusted authority (in this case verification of certificates chain is needed.) What I meant is for SAML Token profile, step 2 is not needed. > > > > For SOAP > > message verification on the rely-party side, the rely-party do not need > to > > verify the certificates chain of "subject". > > I'm not sure I follow you. How does the presenter of the SOAP request > (with SAML token in the SOAP header) authenticate to the SOAP > responder? "authentication" here could not be accurate. SOAP presentor authenticates (via TLS, or SOAP message authentication by using X.509 token) to 3-party authority (trusted by rely-party), and gets back SAML Token (with the presentor's public key, or certificate inside as part of <saml:SubjectConfirmation>); Then uses its' own private key to sign soap message; Afterwards rely-party can verify the signature to SOAP message (simple verification is needed, just verify that the private key which signes the SOAP message corresponds to the public key in the <saml:SubjectConfirmation>), as well as verify the signature to <saml:Assertion> (simple verification + verifying the certificate in <ds:Signature> is trusted). > > > > <ds:KeyValue> is also convinient for proxy certificate, in my opinion. > > I don't see what <ds:KeyValue> gains you in this case, but I may be > missing something. Unless you can provide a good reason for using > <ds:KeyValue>, I recommend <ds:X509SubjectName> or <ds:X509SKI>, in > that order. The <ds:X509SubjectName> element is simplest for proxy > certificates, I think. It is equivalent to the subject confirmation > implied in VOMS proxies, in fact. Probably <ds:KeyValue> can not gain more than <ds:X509Certificate> (formerly I supposed the <ds:KeyValue> should be standarlized) . But by using <ds:X509SubjectName>, what is the way to get the public key, which is required when verifying the signature to SOAP message. > > > In any event, I should point out that the SAML V2.0 Holder-of-Key > Assertion Profile is now in its formal Public Review period, and it > does not profile <ds:KeyValue>, so if you think that's an error of > omission, it would be good if you could submit a public comment to > that effect. > > http://lists.oasis-open.org/archives/security-services/200903/msg00062.html Is any of the draft you mentioned in this link supposed to update/replace the WS-Security SAML Token 1.1 profile? Weizhong Qiang > > > > 4. Use <saml:Statement> instead of <saml:AttributeStatement>. > > Why? The <saml:Statement> element is abstract so that would require a > type. What type do you recommend (if not > saml:AttributeStatementType)? > > Tom > > > On Mon, Mar 30, 2009 at 5:00 PM, Tom Scavo <trscavo(a)gmail.com> wrote: > >> > >> Hi Weizhong, > >> > >> Can you outline why you think the VOMS SAML assertion is not > >> compatible with the WSS SAML Token Profile? > >> > >> Thanks, > >> Tom > >> > >> PS. The comments quoted below mostly refer to a VOMS SAML assertion > >> bound to an X.509 proxy certificate (but the requirements are not the > >> same as a VOMS SAML assertion bound to SOAP header). > >> > >> On Mon, Mar 30, 2009 at 10:25 AM, weizhong qiang > >> <weizhongqiang(a)gmail.com> wrote: > >> > hi voms folks, all, > >> > The current voms SAML assertion is not compatible with WS-Security > SAML > >> > Token profile. I would ask is there any plan to change it to make it > be > >> > compatible? I ask this because I think if so, the SAML assertion can > be > >> > used > >> > for SOAP message layer authentication, other than just including SAML > >> > attribute assertion. > >> > > >> > > >> > Thanks > >> > Weizhong Qiang > >> > > >> > > >> > On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo(a)gmail.com> wrote: > >> >> > >> >> Thanks to Benjamin for posting this VOMS-SAML response to gt-user. A > >> >> critique (of the SAML, not Benjamin :) follows. > >> >> > >> >> - Note that the output is a <samlp:Response> element, not a > >> >> <saml:Assertion> element. This is wrong. The requester must consume > >> >> the response. Not sure why this isn't happening. > >> >> > >> >> - The value of the <saml:Issuer> element in the response is a DN but > >> >> the Format XML attribute is missing. This is a bug. The default > >> >> Format is "unspecified" but clearly this is not. > >> >> > >> >> - Second-level status codes are desirable so they can be echoed on > the > >> >> command line (if any). > >> >> > >> >> - Same comment about the <saml:Issuer> element in the assertion. > >> >> > >> >> - The use of SAML metadata requires that the Format on the > >> >> <saml:Issuer> element be "entity" but clearly it is not. Thus the > use > >> >> of SAML metadata by the relying party is precluded. > >> >> > >> >> - Don't know if Shibboleth/OpenSAML can verify the signature (which > is > >> >> tricky business). This is a future experiment that needs to be done. > >> >> > >> >> - The <saml:SubjectConfirmation> element contains a > >> >> <ds:X509Certificate> element, which precludes the binding of this > >> >> holder-of-key assertion to a proxy certificate. This is a bug. Use > a > >> >> <ds:X509SubjectName> element instead (which causes the NameID itself > >> >> to be redundant). > >> >> > >> >> - If the assertion is bound to a proxy certificate, the NotBefore and > >> >> NotOnOrAfter attributes are redundant and superfluous. In fact, they > >> >> may be wrong since they must agree with the NotBefore and > NotOnOrAfter > >> >> fields of the proxy. > >> >> > >> >> - Since the client authenticated directly to the server, a > >> >> <saml:AuthnStatement> is desirable (not required, but potentially > >> >> useful at the relying party). > >> >> > >> >> - The NameFormat XML attribute on the <saml:Attribute> element should > >> >> be "uri" not "unspecified". > >> >> > >> >> - The "xsi:" prefix on the <saml:AttributeValue> element is > undefined. > >> >> This is a bug. > >> >> > >> >> - The <saml:AttributeValue> elements do not conform to the XACML > >> >> Attribute Profile (actually, I don't think the attributes conform to > >> >> *any* SAML V2.0 attribute profile). > >> >> > >> >> Hope this helps, > >> >> Tom > >> >> > >> >> ---------- Forwarded message ---------- > >> >> From: Benjamin Henne <henne(a)rvs.uni-hannover.de> > >> >> Date: Wed, Feb 4, 2009 at 1:59 AM > >> >> Subject: Re: [gt-user] SAML based VOMS Server > >> >> To: Tom Scavo <trscavo(a)gmail.com> > >> >> Cc: GT User <gt-user(a)globus.org> > >> >> > >> >> > >> >> <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" > >> >> xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > >> >> ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6" > >> >> InResponseTo="_qwertyuiopasdfghjklzxcvbn" > >> >> IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0"> > >> >> <saml:Issuer > >> >> > >> >> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN= > voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >> >> <Status> > >> >> <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > >> >> </Status> > >> >> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > >> >> ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac" > >> >> IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0"> > >> >> > >> >> > >> >> <saml:Issuer>CN=voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > >> >> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >> >> <ds:SignedInfo> > >> >> <ds:CanonicalizationMethod > >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> > >> >> <ds:SignatureMethod > >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> > >> >> <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"> > >> >> <ds:Transforms> > >> >> <ds:Transform > >> >> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > >> >> <ds:Transform > >> >> > >> >> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n# > "><ec:InclusiveNamespaces > >> >> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds > saml > >> >> xs"/></ds:Transform> > >> >> </ds:Transforms> > >> >> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1 > "/> > >> >> <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue> > >> >> </ds:Reference> > >> >> </ds:SignedInfo> > >> >> <ds:SignatureValue> > >> >> ... > >> >> </ds:SignatureValue> > >> >> > >> >> > >> >> > <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature> > >> >> <saml:Subject> > >> >> <saml:NameID > >> >> > >> >> > >> >> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin > >> >> Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID> > >> >> <saml:SubjectConfirmation > >> >> Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> > >> >> <saml:SubjectConfirmationData> > >> >> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > >> >> <ds:X509Data> > >> >> <ds:X509Certificate>...</ds:X509Certificate> > >> >> </ds:X509Data> > >> >> </ds:KeyInfo> > >> >> </saml:SubjectConfirmationData> > >> >> </saml:SubjectConfirmation> > >> >> </saml:Subject> > >> >> <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z" > >> >> NotOnOrAfter="2008-10-17T06:03:57.920Z"/> > >> >> <saml:AttributeStatement> > >> >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles" > >> >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">staff@/RVS/research/SAML</saml:AttributeValue> > >> >> </saml:Attribute> > >> >> <saml:Attribute Name="nationality" > >> >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">German</saml:AttributeValue> > >> >> </saml:Attribute> > >> >> <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group" > >> >> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">/RVS/education</saml:AttributeValue> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">/RVS</saml:AttributeValue> > >> >> <saml:AttributeValue > >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema" > >> >> xsi:type="xs:string">/RVS/research</saml:AttributeValue> > >> >> </saml:Attribute> > >> >> </saml:AttributeStatement> > >> >> </saml:Assertion> > >> >> </Response> > >> > > >> > > > > > >

2 1

Re: [Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?
by weizhong qiang 30 Mar '09

30 Mar '09

hi voms folks, all, The current voms SAML assertion is not compatible with WS-Security SAML Token profile. I would ask is there any plan to change it to make it be compatible? I ask this because I think if so, the SAML assertion can be used for SOAP message layer authentication, other than just including SAML attribute assertion. Thanks Weizhong Qiang On Tue, Feb 10, 2009 at 5:21 AM, Tom Scavo <trscavo(a)gmail.com> wrote: > Thanks to Benjamin for posting this VOMS-SAML response to gt-user. A > critique (of the SAML, not Benjamin :) follows. > > - Note that the output is a <samlp:Response> element, not a > <saml:Assertion> element. This is wrong. The requester must consume > the response. Not sure why this isn't happening. > > - The value of the <saml:Issuer> element in the response is a DN but > the Format XML attribute is missing. This is a bug. The default > Format is "unspecified" but clearly this is not. > > - Second-level status codes are desirable so they can be echoed on the > command line (if any). > > - Same comment about the <saml:Issuer> element in the assertion. > > - The use of SAML metadata requires that the Format on the > <saml:Issuer> element be "entity" but clearly it is not. Thus the use > of SAML metadata by the relying party is precluded. > > - Don't know if Shibboleth/OpenSAML can verify the signature (which is > tricky business). This is a future experiment that needs to be done. > > - The <saml:SubjectConfirmation> element contains a > <ds:X509Certificate> element, which precludes the binding of this > holder-of-key assertion to a proxy certificate. This is a bug. Use a > <ds:X509SubjectName> element instead (which causes the NameID itself > to be redundant). > > - If the assertion is bound to a proxy certificate, the NotBefore and > NotOnOrAfter attributes are redundant and superfluous. In fact, they > may be wrong since they must agree with the NotBefore and NotOnOrAfter > fields of the proxy. > > - Since the client authenticated directly to the server, a > <saml:AuthnStatement> is desirable (not required, but potentially > useful at the relying party). > > - The NameFormat XML attribute on the <saml:Attribute> element should > be "uri" not "unspecified". > > - The "xsi:" prefix on the <saml:AttributeValue> element is undefined. > This is a bug. > > - The <saml:AttributeValue> elements do not conform to the XACML > Attribute Profile (actually, I don't think the attributes conform to > *any* SAML V2.0 attribute profile). > > Hope this helps, > Tom > > ---------- Forwarded message ---------- > From: Benjamin Henne <henne(a)rvs.uni-hannover.de> > Date: Wed, Feb 4, 2009 at 1:59 AM > Subject: Re: [gt-user] SAML based VOMS Server > To: Tom Scavo <trscavo(a)gmail.com> > Cc: GT User <gt-user(a)globus.org> > > > <Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > ID="_d01d46b7-d16a-4ae8-b9bb-beb8844838b6" > InResponseTo="_qwertyuiopasdfghjklzxcvbn" > IssueInstant="2008-10-16T19:03:57.922Z" Version="2.0"> > <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">CN= > voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > <Status> > <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > </Status> > <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > ID="_81b685e5-4650-4ba9-b1c6-0ed957cc33ac" > IssueInstant="2008-10-16T19:03:57.920Z" Version="2.0"> > <saml:Issuer>CN=voms3.gridlab.uni-hannover.de > ,OU=UniHannover,O=GermanGrid,C=DE</saml:Issuer> > <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > <ds:SignedInfo> > <ds:CanonicalizationMethod Algorithm=" > http://www.w3.org/2001/10/xml-exc-c14n#"/> > <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1 > "/> > <ds:Reference URI="#_81b685e5-4650-4ba9-b1c6-0ed957cc33ac"> > <ds:Transforms> > <ds:Transform Algorithm=" > http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> > <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n# > "><ec:InclusiveNamespaces > xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml > xs"/></ds:Transform> > </ds:Transforms> > <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> > <ds:DigestValue>j55K/cn8GQNuTQ52Kr3r0NGRJ0w=</ds:DigestValue> > </ds:Reference> > </ds:SignedInfo> > <ds:SignatureValue> > ... > </ds:SignatureValue> > > <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature> > <saml:Subject> > <saml:NameID > > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Benjamin > Henne,OU=UniHannover,O=GermanGrid,C=DE</saml:NameID> > <saml:SubjectConfirmation > Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"> > <saml:SubjectConfirmationData> > <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> > <ds:X509Data> > <ds:X509Certificate>...</ds:X509Certificate> > </ds:X509Data> > </ds:KeyInfo> > </saml:SubjectConfirmationData> > </saml:SubjectConfirmation> > </saml:Subject> > <saml:Conditions NotBefore="2008-10-16T19:03:57.920Z" > NotOnOrAfter="2008-10-17T06:03:57.920Z"/> > <saml:AttributeStatement> > <saml:Attribute Name="http://voms.forge.cnaf.infn.it/roles" > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">VO-Admin@/RVS</saml:AttributeValue> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">resass@/RVS/education</saml:AttributeValue> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">staff@/RVS/research/SAML</saml:AttributeValue> > </saml:Attribute> > <saml:Attribute Name="nationality" > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">German</saml:AttributeValue> > </saml:Attribute> > <saml:Attribute Name="http://voms.forge.cnaf.infn.it/group" > NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">/RVS/education</saml:AttributeValue> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">/RVS</saml:AttributeValue> > <saml:AttributeValue > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xsi:type="xs:string">/RVS/research</saml:AttributeValue> > </saml:Attribute> > </saml:AttributeStatement> > </saml:Assertion> > </Response> >

2 2