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

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, According to the specification of SAML Token profile 1.1 ( http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SA…) I listed the difference as follows, some of the points are trivial . For a SAML Token which is compliant to SAML V1.1: <saml:Assertion xmlns:saml="..." AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2005-05-27T16:53:33.173Z" Issuer=”www.opensaml.org” MajorVersion="1" MinorVersion="1"> <saml:Conditions NotBefore="2005-05-27T16:53:33.173Z" NotOnOrAfter="2005-05-27T16:58:33.17302Z"/> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier NameQualifier="www.example.com" Format=“urn:oasis:names:tc:SAML:1.1:nameid- format:X509SubjectName”> uid=joe,ou=people,ou=saml-demo,o=baltimore.com </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:holder-of-key </saml:ConfirmationMethod> <ds:KeyInfo> <ds:KeyValue>...</ds:KeyValue> </ds:KeyInfo> </saml:SubjectConfirmation> </saml:Subject> <saml:Attribute AttributeName="MemberLevel" AttributeNamespace="http://www.oasis- open.org/Catalyst2002/attributes"> <saml:AttributeValue>gold</saml:AttributeValue> </saml:Attribute> <saml:Attribute AttributeName="E-mail" AttributeNamespace=" http://www.oasis-open.org/Catalyst2002/attributes"> <saml:AttributeValue>joe(a)yahoo.com</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <ds:Signature>...</ds:Signature> </saml:Assertion> For a SAML Token which is compliant to SAML V2.0: <saml2:Assertion xmlns:saml2="..." xmlns:xsi="..." ID=”_a75adf55-01d7-40cc-929f-dbd8372ebdfc”> <saml2:Subject> <saml2:NameID> ... </saml2:NameID> <saml2:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”> <saml2:SubjectConfirmationData xsi:type="saml2:KeyInfoConfirmationDataType"> <ds:KeyInfo> <ds:KeyValue>...</ds:KeyValue> </ds:KeyInfo> </saml2:SubjectConfirmationData> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Statement> ... </saml2:Statement> <ds:Signature>...</ds:Signature> </saml2:Assertion> Suppose voms saml assertion uses SAML V2.0 Some comments: 1. The signature for <saml:Reponse> could also be necessary, even though the integrity is guaranteed by TLS. 2. xml attribute xsi:type="saml2:KeyInfoConfirmationDataType" could be necessary for <saml2:SubjectConfirmationData/> 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. For SOAP message verification on the rely-party side, the rely-party do not need to verify the certificates chain of "subject". <ds:KeyValue> is also convinient for proxy certificate, in my opinion. 4. Use <saml:Statement> instead of <saml:AttributeStatement>. Cheers, Weizhong 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> > > > > >

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 Valerio Venturi 30 Mar '09

30 Mar '09

On Mon, 2009-03-30 at 11:00 -0400, Tom Scavo 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). Correct, and please note that the Strawman profiles the use of SAML assertions in the SOAP Header, not bound with a proxy. Anyway we got that as a use case and are willing to work in a direction that can accomodate both uses. Valerio > 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> > > > >

1 0

Re: [Pgi-wg] MWSG Meeting Slides (Drafts) - OpenSSL and GSI areincompatible but use identical X509 proxies
by m.riedel＠fz-juelich.de 30 Mar '09

30 Mar '09

Hi Etienne, thanks for the research. >- 1) OpenSSL and GSI are really incompatible as transport layers. Confirmed, mainly because the do GSI/HTTP making it HTTPG basically... >- 2) But they now accept exactly the same RFC compliant X509 proxies. Good news - and helpful for GridFTP probably - so you may use openssl proxies with GridFTP, so GSI is not required anymore for GridFTP then... >- 3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden That's clear. >- I suggest that you provide information 2 and 3 at the beginning of the first slide 'TLS with GSI Proxies'. I will do it. Thanks, 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 ------------------------------------------------------------------- ------------------------------------------------------------------- Morris, Concerning the MWSG Meeting Slides : About X509 proxies, I just got confirmation from Vincenzo CIASCHINI that : 1) OpenSSL and GSI are really incompatible as transport layers. 2) But they now accept exactly the same RFC compliant X509 proxies. 3) Old-style GSI X509 proxies are obsolete, and their usage should be forbidden I suggest that you provide information 2 and 3 at the beginning of the first slide 'TLS with GSI Proxies'. 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 ---------------------------------- On Mon, 30 Mar 2009, m.riedel(a)fz-juelich.de wrote: > 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 > ------------------------------------------------------------------- > -------------------------------------------------------------------

1 0

MWSG Meeting
by Steven Newhouse 30 Mar '09

30 Mar '09

All, For those interested in dialing in for the PGI presentation and discussion at the Middleware Security Group meeting on Tuesday at 2pm (local) - here are the details. Note Europe has entered daylight saving time so the USA is now back in sync! Steven Event name: MWSG PGI Presentation Coordinator: Name: Christoph Witzig Institution: SWITCH Start date/time: Tue, 2009-03-31 13:50 (Swiss local time) Tue, 2009-03-31 11:50 (UTC) Duration: 01:30 h Number of participants: 10 H.323 (IP) conference dialin: 0041 44 250 96 85 H.320 (ISDN) conference dialin: +41 44 250 96 85 SIP (IP) conference dialin: 85(a)mcu.switch.ch Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse

1 0

Reminder: task for all, today (Monday)
by Johannes Watzl 29 Mar '09

29 Mar '09

Hello, just to remind you. as agreed on Friday a task for all: Comment on Morris' slides on Monday, 30 March 2009 Best wishes, Johannes -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room D0.5, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

1 0

Re: [Pgi-wg] OGF PGI - Security Model
by Duane Merrill 28 Mar '09

28 Mar '09

If the PGI working group wants to describe "compliance with GSI" (as is mentioned in several places above, e.g., 5.3, 5.4, 7.3, etc.), then the working group MUST reference or produce a publication that defines what GSI Compliance means. Also, you may have to spend a lot of political capital to get agreement on the GLUE schema as a way of describing and discovering secure communication requirements, particularly since WS-SecurityPolicy exists as an OASIS recommendation for doing just that. You may want to reconsider the mandates of a 6, as it will likely turn into a sticking point. Duane > On 3/27/09, Etienne URBAH <urbah(a)lal.in2p3.fr> wrote: >> To All, >> >> >> In order to handle X509 proxies, we regrettably have to take into >> account both the OpenSSL and GSI implementations of TLS, which are >> incompatible. >> >> >> So I have updated my 'PGI Security Model' below and at >> http://forge.gridforum.org/sf/go/doc15584?nav=1 >> >> >> OGF PGI - Security Model >> ======================== >> >> >> Current Established Base >> ======================== >> Chapters 1, 2 and 3 below describe the current security model of >> Computing Grid Infrastructures. >> >> >> 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 installs the >> CA Certificates it deems necessary. In general, there is no requirement >> to keep them up-to-date, but typically it is considered a security >> update and as such is strongly recommended to apply. Some >> infrastructures issue warnings for sites with outdated CA certs, but >> normally it does not impede operations. >> >> 1.8) Using its X509 certificate, each grid User can create at any time >> a (usually short lived) X509 proxy with permits impersonation / >> delegation during a (usually short) period. >> >> >> 2) Virtual Organizations >> ------------------------- >> 2.1) A Virtual Organization (VO) groups grid Users (usually with common >> goals). A Virtual Organization may be a legal body, and may be a >> Certificate Authority which can issue X509 certificates, but most are >> NOT. >> >> 2.2) Inside DEISA, a Virtual Community also groups grid Users with >> common goals. {{{The relationships between Virtual Communities and >> Virtual Organizations have to be explained by Morris RIEDEL}}} >> >> 2.3) Each grid User belongs to 1 or more VO (Virtual Organization), >> which grants him access rights to grid Storage and Computing Resources. >> >> 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) Some grid Infrastructures provide an Information Service with >> describes the Infrastructure, for example according to the 'GLUE 1.3' >> schema. >> >> 3.2) If this Information Service exists, then each grid User can query >> it in order to discover the list, requirements and capabilities of 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 >> has to present either (depending on the Infrastructure) : >> 3.3.1) the public part of his X509 certificate, or >> 3.3.2) the public part of his X509 proxy (without VOMS >> extensions), or >> 3.3.3) the public part of his VOMS proxy, or >> 3.3.4) a bag of SAML assertions. >> In order to handle X509 proxies, both the OpenSSL and GSI >> implementations of TLS are widely used, but they are INCOMPATIBLE. >> If the grid User accesses data through a interface requiring >> delegation, then the next subchapter applies. >> >> 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 is >> either (depending on the Infrastructure) : >> 3.4.1) an X509 proxy, or >> 3.4.2) a VOMS proxy, or >> 3.4.3) a bag of SAML assertions. {{{Morris RIEDEL has to >> explain if and how delegation of SAML assertions work}}} >> >> 3.5) Each grid Site providing grid Services to grid Users has installed >> Authorization Files (such as 'gridmap' files) describing VOMS >> authorizations, other authorizations, and mapping of grid credentials to >> local credentials. Grid Sites try to keep those Authorization Files up >> to date. >> There is a trend to replace these static 'gridmap' files by a >> robust Authorization Service (SCAS by EGEE, GUMS by OSG). >> >> >> >> Where we propose to go >> ====================== >> Chapters 4, 5, 6 and 7 below describe a security model for short term >> Interoperability between Computing Grid Infrastructures. >> >> >> 4) Operational Robustness of Security >> -------------------------------------- >> 4.1) The number of Certificate Authorities for grid Infrastructures >> SHOULD be kept as low as possible. >> >> >> 5) Interoperability between X509 certificates and X509 proxies for >> Authentication >> ---------------------------------------------------------------------------------- >> 5.1) For this short term Security Profile aimed at short term >> Interoperability, we accept Shibboleth as an option, but knowingly >> exclude Shibboleth from any requirement. >> >> 5.2) X509 proxies MUST fully comply either to RFC 3820 or to GSI. >> >> 5.3) VOMS services, which deliver X509 proxies with VOMS extensions, >> MUST fully comply either to RFC 3820 or to GSI. >> >> 5.4) The authentication library used by grid Services MUST fully comply >> either to RFC 3820 or to GSI. >> >> >> 6) Information Service describing the Infrastructure according the the >> GLUE2 schema >> ------------------------------------------------------------------------------------ >> 6.1) Each grid Infrastructure MUST provide an Information Service, >> which describes the Infrastructure according the the GLUE2 schema. >> >> 6.2) If access to the Information Service is restricted, the grid >> Infrastructure MUST provide a Bootstrap Information Service, with >> describes the security requirements for access to the full Information >> Service according the the GLUE2 schema. >> >> >> 7) Interoperable Grid Services : Information, AUTHN, AUTHZ >> ------------------------------------------------------------ >> 7.1) The semantics of Authorization tokens MUST be the same for all >> grid Infrastructures. >> Examples of Authorization tokens are : >> 7.1.1) DN of the X509 certificate or proxy >> 7.1.2) VOMS-style Attribute Certificates >> 7.1.3) Restriction attributes >> 7.1.4) Shibboleth >> >> 7.2) The Information Service of each grid Infrastructure MUST describe, >> for each grid Service, the security requirements for access to the grid >> Service, and which Authorization Tokens this Service expects >> (potentially several). >> >> 7.3) The Information Service of each grid Infrastructure MUST describe >> the transport method that the grid Service expects (potentially several). >> In order to handle X509 proxies, we regrettably have to take into >> account both the OpenSSL and GSI implementations of TLS, which are >> incompatible. >> >> 7.4) Each grid Site providing grid Services to grid Users MUST install >> and keep up to date a robust Authorization Service enforcing VOMS >> authorizations, other authorizations, and mapping of grid credentials to >> local credentials. >> >> 7.5) Each grid Service MUST accept at least : >> 7.5.1) One of the following Authorization Tokens : >> - DN of the X509 certificate or proxy >> - X509 VOMS-style Attribute Certificates (VOMS >> extensions) >> They are defined in 'VOMS Attribute Certificate >> Format' at http://forge.gridforum.org/sf/go/doc13797?nav=1 >> - X509 restriction attributes >> {{{Please give the reference of a description >> document}}} >> - SAML assertions >> {{{Please give the reference of a description >> document}}} >> 7.5.2) One of the following transport methods : >> - OpenSSL (compliant to RFC 3820) for attributes of X509 >> proxies >> - GSI for attributes of X509 proxies >> - SOAP header for SAML assertions >> >> 7.6) As long as it satisfies subchapter 7.5, each grid Service MAY also >> accept Authentication and Authorization methods based on Shibboleth. >> >> 7.7) In order to ease the development and deployment of grid Clients, >> each grid Service SHOULD accept following types of Authorization Tokens : >> 7.7.1) X509 VOMS-style Attribute Certificates (VOMS extensions) >> 7.7.2) X509 restriction attributes. >> In the 2 previous cases, the grid Service SHOULD accept >> that they are transported through OpenSSL (compliant to RFC 3820). >> Transport through GSI is explicitly DEPRECATED. >> 7.7.3) SAML assertions. >> In that case, the grid Service SHOULD accept that they >> are transported inside SOAP headers. >> >> 7.8) In order to keep middleware complexity and bandwidth usage as low >> as possible, grid Services should NOT send their full description of >> their security interface inside each message, but only when specifically >> requested (for example by the Information Service). >> >> To be thoroughly criticized ... >> >> >> 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 >> ---------------------------------- >> >

2 1

Re: [Pgi-wg] Figures about Authentication and Authorization plumbings
by Etienne URBAH 27 Mar '09

27 Mar '09

Morris, Concerning the Authentication and Authorization plumbings, I completely agree on the principle : The 1-year goal of PGI is : - NOT that ALL grid Clients can use ALL grid Servers, - but that each grid Client can query the grid Information Service, in order to discover which grid Servers accept the Authentication and Authorization methods that the grid Client is able to use. - and to profile the Authentication and Authorization methods, in order to reduce the number of incompatible grid islands. 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 ---------------------------------- On Fri, 27 Mar 2009, Morris Riedel wrote: > Hi team, > > actually I drafted three figures for AuthZ plumbings as well: > > http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc > man.root.meeting_materials.2009_03_30_mwsg_pgi_talk/doc15588 > > > have a look if you find time - and please feel free to look and/or modify > the ppt as you like. > > Hear you soon in the TelCon, > Morris > > > > ------------------------------------------------------------ > Morris Riedel > SW - Engineer > Distributed Systems and Grid Computing Division > Jülich Supercomputing Centre (JSC) > Forschungszentrum Juelich > Wilhelm-Johnen-Str. 1 > D - 52425 Juelich > Germany > > Email: m.riedel(a)fz-juelich.de > Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel > Phone: +49 2461 61 - 3651 > Fax: +49 2461 61 - 6656 > > Skype: MorrisRiedel

1 0

PGI Vocabulary wiki
by Johannes Watzl 27 Mar '09

27 Mar '09

Dear all, as an initial input for our PGI vocabulary Wiki, I put a number of abbreviations and terms used in the PGI discussions on the GridForge site (Wiki) as initial input. To have a clear definition of each of these "things" and to be sure everybody has the same in mind talking about this or that, I kindly ask you to contribute to this vocabulary. Hear you soon! Cheers, Johannes -- _ _ _ _ _ _ Johannes Watzl |\/| |\ | |\/| Institut für Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universität München ======= TEAM ======= Oettingenstr. 67, 80538 Munich, Germany Room D0.5, Phone +49-89-2180-9162 Munich Network Management Team Email: watzl(a)nm.ifi.lmu.de Münchner Netz-Management Team http://www.nm.ifi.lmu.de/~watzl

2 1

More detailed security technical survey
by weizhong qiang 27 Mar '09

27 Mar '09

hi all, I just added a more detailed table about security survey onto PGI wiki, as I promised. Please take a look and fill/change it correspondingly. Cheers Weizhong

1 1

Re: [Pgi-wg] OGF PGI - Security Strawman
by Duane Merrill 27 Mar '09

27 Mar '09

Yes. For example, an idealized TLS-Proxy-service-plumbing can equally accommodate a TLS-EEC-client-plumbing as well as a TLS-Proxy-client plumbing. (Those two client plumbings are very different, but work equally well with the single service plumbing.) Duane On 3/27/09, Morris Riedel <m.riedel(a)fz-juelich.de> wrote: > Service/Client plumbings? > > > > I rather refer to: > > > > 3 suggested Authentication Plumbings > > 2 suggested Authorization Plumbings > > > > Take care, > Morris > > > > ------------------------------------------------------------ > > Morris Riedel > > SW - Engineer > > Distributed Systems and Grid Computing Division > > Jülich Supercomputing Centre (JSC) > > Forschungszentrum Juelich > > Wilhelm-Johnen-Str. 1 > > D - 52425 Juelich > > Germany > > > > Email: m.riedel(a)fz-juelich.de > > Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel > > Phone: +49 2461 61 - 3651 > > Fax: +49 2461 61 - 6656 > > > > Skype: MorrisRiedel > > > > "We work to better ourselves, and the rest of humanity" > > > > Sitz der Gesellschaft: Jülich > > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > > Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe > > Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), > > Dr. Ulrich Krafft (stellv. Vorsitzender) > > > > From: Duane Merrill [mailto:dgm4d@virginia.edu] > Sent: Friday, March 27, 2009 3:50 PM > To: Morris Riedel > Cc: Aleksandr Konstantinov; pgi-wg(a)ogf.org > Subject: Re: [Pgi-wg] OGF PGI - Security Strawman > > > > Since we are talking about dynamically advertising the requirements of > services (and not clients) within hypothetical information services, we > should talk explicily about "service plumbing" and not "client plumbing". > For example: > > * Service endpoint requires xyz (e.g., delegation-step, WS-Addressing > reference parameters, TLS mutual authentication, etc.) > * Service endpoint can accept xyz (e.g., TLS proxy-path-validation, > SOAP WS-S proxy-path-validation, PGI VOMS-ACs, PGI SAML ACs, TLS > client-anonymous authentication, etc) > > It is implicit that we will be putting in effort to implement clients that > fit within the realm of options provided by the services that those clients > intend to use. (And it is has become clear from several from these email > threads which services those are.) > > > > Thus "grid islands" become "grid DAGs". > > > > -Duane > > > > > > > > 2009/3/27 Morris Riedel <m.riedel(a)fz-juelich.de> > > > > Hi, > > > >>- Currently all sentence are read on this mailing lists looked like > > requiring only listed options to be used for authorization. And this is > > wrong from my point of view. > > > > > > I refer to two different plumbings nothing more. This already narrows down > > the thousand other possibilities... > > > > Take care, > > Morris > > > > > > ------------------------------------------------------------ > > Morris Riedel > > SW - Engineer > > Distributed Systems and Grid Computing Division > > Jülich Supercomputing Centre (JSC) > > Forschungszentrum Juelich > > Wilhelm-Johnen-Str. 1 > > D - 52425 Juelich > > Germany > > > > Email: m.riedel(a)fz-juelich.de > > Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel > > Phone: +49 2461 61 - 3651 > > Fax: +49 2461 61 - 6656 > > > > Skype: MorrisRiedel > > > > "We work to better ourselves, and the rest of humanity" > > > > Sitz der Gesellschaft: Jülich > > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > > Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe > > Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), > > Dr. Ulrich Krafft (stellv. Vorsitzender) > > > > > >>------Original Message----- > >>-From: Aleksandr Konstantinov [mailto:aleksandr.konstantinov@fys.uio.no] > > > >>-Sent: Friday, March 27, 2009 2:40 PM > >>-To: Morris Riedel > >>-Cc: pgi-wg(a)ogf.org > >>-Subject: Re: [Pgi-wg] OGF PGI - Security Strawman > >>- > > > >>-On Friday 27 March 2009 14:39, Morris Riedel wrote: > >>-> But Aleksandr - I think we all agree to the VOMS scenario - come on > > that’s > >>-> something where we can't go currently... :-) > >>- > >>-As I already said I'm not suggesting to profile other information whihc > > can be used > >>-for authorization. > >>-I said that such information should not be disallowed. Just write profile > > in such way > >>-that other options > >>-are up to deployment. Currently all sentence are read on this mailing > > lists looked like > >>-requiring only > >>-listed options to be used for authorization. And this is wrong from my > > point of view. > >>- > >>- > >>-A.K. > >>- > >>- > >>- > >>-> > >>-> ------------------------------------------------------------ > >>-> Morris Riedel > >>-> SW - Engineer > >>-> Distributed Systems and Grid Computing Division > >>-> Jülich Supercomputing Centre (JSC) > >>-> Forschungszentrum Juelich > >>-> Wilhelm-Johnen-Str. 1 > >>-> D - 52425 Juelich > >>-> Germany > >>-> > >>-> Email: m.riedel(a)fz-juelich.de > >>-> Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel > >>-> Phone: +49 2461 61 - 3651 > >>-> Fax: +49 2461 61 - 6656 > >>-> > >>-> Skype: MorrisRiedel > >>-> > >>-> "We work to better ourselves, and the rest of humanity" > >>-> > >>-> Sitz der Gesellschaft: Jülich > >>-> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > >>-> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe > >>-> Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), > >>-> Dr. Ulrich Krafft (stellv. Vorsitzender) > >>-> > >>-> > >>-> >------Original Message----- > >>-> >-From: Aleksandr Konstantinov > > [mailto:aleksandr.konstantinov@fys.uio.no] > >>-> >-Sent: Friday, March 27, 2009 1:29 PM > >>-> >-To: Morris Riedel > >>-> >-Subject: Re: [Pgi-wg] OGF PGI - Security Strawman > >>-> >- > >>-> >-On Friday 27 March 2009 12:24, you wrote: > >>-> >-> Aleksandr, > >>-> >-> > >>-> >-> could you give me one example for this: > >>-> >-> > >>-> >-> >- I do support idea of attribute based authorization. But can't > >>-> understand > >>-> >-> why other information authenticating the client should be disallowed > >>-> from > >>-> >-> making authorization decision. > >>-> >-> > >>-> >-> > >>-> >-> I seek to understand what you mean. > >>-> >- > >>-> >- > >>-> >-Most brutal example would be DN of X.509 certificate. > >>-> >-More sophisticated could be distrust of specific computing resource > > for > >>-> specific > >>-> >-VOMS service. > >>-> >- > >>-> >-A.K. > > > >>-> > > > > _______________________________________________ > > Pgi-wg mailing list > > Pgi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/pgi-wg > > > > > > > >

1 0