- pgi-wg - lists.ogf.org

Re: [Pgi-wg] Sec: Agreement on attribute transport mechanisms forAttrAuthZ
by Aleksandr Konstantinov 20 Mar '09

20 Mar '09

On Friday 20 March 2009 12:08, Morris Riedel wrote: > Good morning Aleksandr, > > > >-I see no reason for "either". Also it would be nice to define used > terms. > >-AFAIK there are no restrictions for using X.509 proxies (aka PC) in TLS. > As long as > >-we are talking about > >-standardaized PCs (RFC 3820) of course. > >-For infrastructures relying on full or partial/restricted X.509 identity > delegation PC > >-(proxy certificate) is > >-a must. But I see no reason why that should exclude usage of ordinary > X.509 > >-certificates/keys as > >-mean for identifying (direct or through attributes) communicating parties. > > > The reason is basically to precisely define what an endpoint supports, if do > not define this precisely interoperability will break since there is a big > difference using TLS with or without proxies for the authN check. The either I do code for doing authentication with and without proxies. And I never noticed significant difference. > is a reason to make it more simpler although there is a polymorphic > dependency, but this is not always helpful for the implementations. > > Example: > > (a) > For instance, if we would only claim that the UNICORE Gateway (AuthN check > for end-users) supports the PGI_TLS w/o knowing if it uses proxies or not: > > If you then use your ARC-Client with proxies and access the Gateway you > fail, because the AuthN check only checks for full end-entity certificates. > > (b) > For instance, if we would claim that UNICORE Gateway supports PGI_GSI (so > proxies including some newly defined PGI revocation mechanism since this is > a general GSI problem, or proxy problem although they have limited lifetime) > : > > If you then use your ARC client with proxies and access the Gateway you win, > because the AuthN check climbs up the whole proxy-hierarchy. > > If we use our own UNICORE Client with full end-entity certificates it works > as well since PGI_GSI MAY include PGI_TLS (your polymorphic item). So why not to use last option? Or am I missing something? > > ### Conclusions and motivation for either: > > (a) > So clearly every service that do supports PGI_GSI is able to accept client > request based on PGI_TLS only > > (b) > But every service that purely supports PGI_TLS is not able to accept client > requests based on PGI_GSI > > Bottom line: the either is needed for differentiation including inherently > your statement of polymorphism that only indicated 'one direction' or 'is-a' > and not the other direction! If (a) covers (b) then "either (a) or (b)" is not achievable. A.K.

1 0

Re: [Pgi-wg] Sec: Agreement on attribute transport mechanisms forAttrAuthZ
by weizhong qiang 20 Mar '09

20 Mar '09

2009/3/20 Morris Riedel <m.riedel(a)fz-juelich.de> > Good morning Aleksandr, > > > >-I see no reason for "either". Also it would be nice to define used > terms. > >-AFAIK there are no restrictions for using X.509 proxies (aka PC) in TLS. > As long as > >-we are talking about > >-standardaized PCs (RFC 3820) of course. > >-For infrastructures relying on full or partial/restricted X.509 identity > delegation PC > >-(proxy certificate) is > >-a must. But I see no reason why that should exclude usage of ordinary > X.509 > >-certificates/keys as > >-mean for identifying (direct or through attributes) communicating > parties. > > > The reason is basically to precisely define what an endpoint supports, if > do > not define this precisely interoperability will break since there is a big > difference using TLS with or without proxies for the authN check. The > either > is a reason to make it more simpler although there is a polymorphic > dependency, but this is not always helpful for the implementations. IMO, clarification is for sure needed, but "either-or" restriction should not be enforced. The implementation itself should have the ability to judge the EEC (end entity certificate) and PC(proxy certificate) and process them accordingly, instead of rejecting one of them. My personal thinking is, since we are talking about PGI or interoperability, we probably do need to change the current implementation if it can not satisfy interoperability, while keeping the principle that the change should be as little as possible. Regards, Weizhong > > > Example: > > (a) > For instance, if we would only claim that the UNICORE Gateway (AuthN check > for end-users) supports the PGI_TLS w/o knowing if it uses proxies or not: > > If you then use your ARC-Client with proxies and access the Gateway you > fail, because the AuthN check only checks for full end-entity certificates. > > (b) > For instance, if we would claim that UNICORE Gateway supports PGI_GSI (so > proxies including some newly defined PGI revocation mechanism since this is > a general GSI problem, or proxy problem although they have limited > lifetime) > : > > If you then use your ARC client with proxies and access the Gateway you > win, > because the AuthN check climbs up the whole proxy-hierarchy. > > If we use our own UNICORE Client with full end-entity certificates it works > as well since PGI_GSI MAY include PGI_TLS (your polymorphic item). > > ### Conclusions and motivation for either: > > (a) > So clearly every service that do supports PGI_GSI is able to accept client > request based on PGI_TLS only > > (b) > But every service that purely supports PGI_TLS is not able to accept client > requests based on PGI_GSI > > Bottom line: the either is needed for differentiation including inherently > your statement of polymorphism that only indicated 'one direction' or > 'is-a' > and not the other direction! > > > Does it sound more clear now why we need such a mechanism of describing > exactly which of both is needed for AUTH? > > > Take care, > Morris > > > > > > > > > > > > > > > > >------Original Message----- > >-From: pgi-wg-bounces(a)ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf > Of > >-Aleksandr Konstantinov > >-Sent: Friday, March 20, 2009 10:27 AM > >-To: pgi-wg(a)ogf.org > >-Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanisms > >-forAttrAuthZ > >- > >-On Friday 20 March 2009 09:22, m.riedel(a)fz-juelich.de wrote: > >-> Hi PGI Security team, > >-> > >-> after discussing possible AA interface that gives us insights into > the > different > >-"attribute package" formats, we can discuss the transport of them (or as > said by > >-Steven: The presentation of these packages at the (functional services). > >-> > >-> ### Goal: > >-> > >-> (a) > >-> We are discussing the transport of agreed attribute packages that are > used in PGI > >-to achieve attribute-based authorization (overcoming pure id-based > authZ)... > >-> > >-> > >-> (b) > >-> ...because we want to specify exactly where services can expect the > "attribute > >-packages" in the request messages... > >-> > >-> > >-> (c) > >-> ... in order to find out if we can agree on simple "attribute-package" > transport > >-paradigms that are easy to understand and don't allow for too much > flexibility to > >-promote interoperability. > >-> > >-> > >-> ### (Agreed) Attribute Packages so far > >-> > >-> (a) > >-> SAML assertions with attributes of end-users > >-> > >-> (b) > >-> VOMS ACs with attributes of end-users > >-> > >-> > >-> ### StrawmanFoundational: Conveying identity for authentication. > >-> •SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a > >-SSL/TLS transport protocol in which endpoints are mutually authenticated > by X.509 > >-end-entity public key certificates (PKCs). > >-> Supplemental: Conveying authorization attributes describing aspects of > virtual > >-organization membership. > >-> •X.509 proxy + attribute certificates (PGI_TLS_PROXY). X.509 proxy > certificates > >-exchanged at the SSL/TLS level, demonstrating ownership of any X.509 > attribute > >-certificates embedded within. This conformance target derives > foundational > >-requirements from PGI_HTTPS. > >-> •SAML attribute assertions (PGI_SOAP_SAML). Demonstrating ownership of > >-SAML attributes exchanged within the SOAP message header. This > conformance > >-target derives foundational requirements from PGI_HTTPS. > >-> > >-> > >-> > >-> ### proposal of easy plumbings: Attr-based Authorization profile > >-> > >-> The plumbings idea refers to the fact that the PGI security should be > EASY to > >-understand and less flexible compared to the wide variety of (OGF,OASIS) > >-specifications having the least dependencies to other specs as possible. > >-> > >-> // precondition > >-> (a) Authentication profile as one plumbing to be agreed before > (precondition) > >-> Simple: You agree on either on full X.509 certs (TLS) or restricted > X.509 proxies > >-(GSI) on transport level > >- > >-I see no reason for "either". Also it would be nice to define used terms. > >-AFAIK there are no restrictions for using X.509 proxies (aka PC) in TLS. > As long as > >-we are talking about > >-standardaized PCs (RFC 3820) of course. > >-For infrastructures relying on full or partial/restricted X.509 identity > delegation PC > >-(proxy certificate) is > >-a must. But I see no reason why that should exclude usage of ordinary > X.509 > >-certificates/keys as > >-mean for identifying (direct or through attributes) communicating > parties. > >- > >-> > >-> > >-> (b) Attr-based AuthZ profile as another plumbing to be agreed on top of > AuthN > >-> Simple: You agree on either SAML assertions or AC VOMS attribute > packages. > >- > >-Here I see no reason on either again. As long as information carried > inside > >-assertion/attribute is > >-semantically identical (or at least convertable) the envelope used to > carry it is of little > >-importance. > >-Of course both ways should be properly defined - without "this is out > scope and > >-should be provided > >-by other profile" sentences. > >-As for comparing SAML assertions to VOMS AC safety wise both provide > adequate > >-measures for ensuring > >-integrity and ownership of enclosed information. > >- > >-> > >-> (c) transportation profiling (with two ways so far) > >-> > >-> 1: if you agree on SAML assertions we put it in the SOAP header in > WS-Security > >-> (works for both options in AuthN) > >-> > >-> 2: if you agree on VOMS AC we put it in the extensions of X.509 > certificates > >-> (works for both options in AuthN) > >- > >->From point of view of ARC codewise there is no technical problem to > >-support both of them and also other 2 combinations of them as long > >-as all are properly defined. > >-Pesonally I would choose both for ARC services just to increase > interoperability. > >- > >-> > >-> > >-> Bottom Line plumbings -> Simple: One Agreement on AuthN and one > agreement > >-on AuthZ (two plumbings rather independent from each other like within > >-pipes/plumbings in a house such as warm water, sewage, cold water, etc.) > >-> > >-> > >-> Example: It doesn't matter if you put warm water (full X.509 certs for > AuthN) or > >-cold water (proxy X.509 certs for AuthN) into the plumbings/pipes - > important is to > >-know what is in the plumbing and thus the middleware is able to handle it > (possibly > >-via different handlers in modern container designs). > >- > >-If You extend idea of pipes to cars there are modern cars which are able > to run on up > >-to 3 kinds of fuels. Why should Grids be worse? > >- > >-> > >-> ### Possible conclusions > >-> > >-> # We need an easy mechanism to perform attribute-based AuthZ > >-> > >-> # Mechanisms for AuthZ decisions are out of scope as well as having a > specified > >-policy (ACLs, XACML) - they are considered to be implementation detail > >- > >-Do Yu mean "out of scope of this mail thread" or "out of scope of PGI"? > >- > >-> > >-> # We have to agree on the structure / Semantics on attributes (seperate > e-mail > >-thread soon) > >-> > >-> > >-> > >-> ### open Questions: > >-> > >-> Q: Is the plumbings idea just oversimplified? It's not exactly > specified, which can > >-be done after agreeing to its element easily. What is the problem with > the > above > >-mentioned plumbings. > >-> > >-> Q: What are the problems of the PGI communication strawman > differentiation > >-mentioned above? > >-> > >-> So let's discuss this important thread before the telcon, but please > keep the > >-structure and semantics of attributes (FQAN, etc.) out of this discussion > for now > >-(seperate e-mail thread) > >-> > >-> > >-> 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 Jülich GmbH > >-> 52425 Jülich > >-> > >-> Sitz der Gesellschaft: Jülich > >-> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > >-> Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe > >-> Geschäftsführung: 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 > >-> > >-_______________________________________________ > >-Pgi-wg mailing list > >-Pgi-wg(a)ogf.org > >-http://www.ogf.org/mailman/listinfo/pgi-wg > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

3 2

Re: [Pgi-wg] Documenting the security agreement/info progress
by Duane Merrill 20 Mar '09

20 Mar '09

The "track-changes" and "insert comments" feature for MS Word documents has come in very handy in other OGF working groups. The "insert comments" feature is particularly useful for allowing discussions on particular aspects to flow on with perfect contextual reference. 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > Hi PGI security folks, > > I'm thinking how we can document progress in agreements in terms of > security. Just let the flow of e-mails run us out of time is not a good > idea... > > > Also, the strawmen document is nice but it is a Formula 1 racecar (or US: > Indy500 car) compared to a bicycle, which is more needed by PGI in the > moment to agree on important 'forward-bringing elements' before profiling > it > precisely to realize a common view on a racecar. > > > As I said earlier - our common agreement (not only in security) is crucial > - > rushing a profile out is not collaborative enough and had nearly crushed > the > group instead of getting us out of the security hole mentioned by Steven > earlier. In slightly other words - it's the process - not the documentation > alone, especially in collaborative efforts. > > > So - I hesitate to again come up with a big document during the agreement > process and rather prefer a condensed WIKI page. > > > But also this page implies changes by numerous folks making again > unreviewable without having any 'place constraints' especially having not > really a good track changes option! > > > My current idea is around so-called factsheets that are only two-page word > documents for each security topic making it condensed and allowing the > valuable track changes functionality including one picture per topic that > represents our common agreement aligned with some text that later lays the > foundation for our 'one' document mentioned in the charter. > > > I just want to hear your opinions on this before I start working on them - > it makes no sense if you disagree. > > I'm also happy to hear better suggestions. > > > Thanks for sharing your views on this, > 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) > > > > _______________________________________________ > Pgi-wg mailing list > Pgi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/pgi-wg > >

3 2

Sec: Agreement on attribute transport mechanisms for AttrAuthZ
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi PGI Security team, after discussing possible AA interface that gives us insights into the different "attribute package" formats, we can discuss the transport of them (or as said by Steven: The presentation of these packages at the (functional services). ### Goal: (a) We are discussing the transport of agreed attribute packages that are used in PGI to achieve attribute-based authorization (overcoming pure id-based authZ)... (b) ...because we want to specify exactly where services can expect the "attribute packages" in the request messages... (c) ... in order to find out if we can agree on simple "attribute-package" transport paradigms that are easy to understand and don't allow for too much flexibility to promote interoperability. ### (Agreed) Attribute Packages so far (a) SAML assertions with attributes of end-users (b) VOMS ACs with attributes of end-users ### StrawmanFoundational: Conveying identity for authentication. •SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a SSL/TLS transport protocol in which endpoints are mutually authenticated by X.509 end-entity public key certificates (PKCs). Supplemental: Conveying authorization attributes describing aspects of virtual organization membership. •X.509 proxy + attribute certificates (PGI_TLS_PROXY). X.509 proxy certificates exchanged at the SSL/TLS level, demonstrating ownership of any X.509 attribute certificates embedded within. This conformance target derives foundational requirements from PGI_HTTPS. •SAML attribute assertions (PGI_SOAP_SAML). Demonstrating ownership of SAML attributes exchanged within the SOAP message header. This conformance target derives foundational requirements from PGI_HTTPS. ### proposal of easy plumbings: Attr-based Authorization profile The plumbings idea refers to the fact that the PGI security should be EASY to understand and less flexible compared to the wide variety of (OGF,OASIS) specifications having the least dependencies to other specs as possible. // precondition (a) Authentication profile as one plumbing to be agreed before (precondition) Simple: You agree on either on full X.509 certs (TLS) or restricted X.509 proxies (GSI) on transport level (b) Attr-based AuthZ profile as another plumbing to be agreed on top of AuthN Simple: You agree on either SAML assertions or AC VOMS attribute packages. (c) transportation profiling (with two ways so far) 1: if you agree on SAML assertions we put it in the SOAP header in WS-Security (works for both options in AuthN) 2: if you agree on VOMS AC we put it in the extensions of X.509 certificates (works for both options in AuthN) Bottom Line plumbings -> Simple: One Agreement on AuthN and one agreement on AuthZ (two plumbings rather independent from each other like within pipes/plumbings in a house such as warm water, sewage, cold water, etc.) Example: It doesn't matter if you put warm water (full X.509 certs for AuthN) or cold water (proxy X.509 certs for AuthN) into the plumbings/pipes - important is to know what is in the plumbing and thus the middleware is able to handle it (possibly via different handlers in modern container designs). ### Possible conclusions # We need an easy mechanism to perform attribute-based AuthZ # Mechanisms for AuthZ decisions are out of scope as well as having a specified policy (ACLs, XACML) - they are considered to be implementation detail # We have to agree on the structure / Semantics on attributes (seperate e-mail thread soon) ### open Questions: Q: Is the plumbings idea just oversimplified? It's not exactly specified, which can be done after agreeing to its element easily. What is the problem with the above mentioned plumbings. Q: What are the problems of the PGI communication strawman differentiation mentioned above? So let's discuss this important thread before the telcon, but please keep the structure and semantics of attributes (FQAN, etc.) out of this discussion for now (seperate e-mail thread) 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 Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

3 2

REMINDER & Numbers: PGI Security TelCon 4pm CET TODAY
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

Hi PGI team, Just a short reminder for our TelCon: TODAY - 4 pm CET Call-in details as follow: via Skype call +9900827049931906 (free of charge) ordinary phone numbers (local rates) with the 9931906 conference number: Austria 0820 401 15470 Belgium 0703 57 134 France 0826 109 071 Germany +49 (0) 180 500 9527 Switzerland 0848 560 397 Proposed Agenda: 1) Debrief & Discuss the communication strawman document from Catania: http://forge.gridforum.org/sf/docman/do/listDocuments/projects.pgi-wg/docma… 2) Agreements and Discussions about items on the e-mail threads 3) AOB 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) ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

1 0

Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces
by m.riedel＠fz-juelich.de 20 Mar '09

20 Mar '09

ok let dive into them..., ----- Original Message ----- From: weizhong qiang <weizhongqiang(a)gmail.com> Date: Thursday, March 19, 2009 4:57 pm Subject: Re: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces > hi, > I have some questions as following. > > 2009/3/19 Morris Riedel <m.riedel(a)fz-juelich.de> > > > Hi PGI security folks, > > > > another issue I see is the supported attribute authorities and > (more> notably) their interfaces. > > > > Taking our experience from GIN into account and addressing the > message of > > Steven (EGEE) there are still two interfaces to consider in > terms of VOMS. > > Also, as an alternative AA there is Shibboleth quite much used > in the > > space. > > > > ### goal > > > > (a) > > We are discussing which AA can be used in PGI to retrieve > attributes...> > > (b) > > ...because we want to find out which interfaces have to be > supported to get > > attributes... > > > > > > (c) > > ... in order to know more precisely which types of attribute > transport> mechanisms we have to support in PGI. > > > > ### Possible scenarios > > > > A. A user contacts a non-WS-based classic VOMS with a proprietary > > interface, > > but gets a standardized RFC AC > > Do you proposed to use the stadardized RFC AC, instead of the VOMS > AC which > is known as a simplified RFC while de-facto AC. If so, I think it > is not > needed. We can use VOMS AC, because we already have a few > production Grid > systems which have supported it. Well I was aware that VOMS AC are compliant with RFC AC's - I didn't know that they reduced the complexity of the specification. Can you point me to a standard specification of AC VOMS then - or this really purely de-facto?! > > > > > back with the attributes signed by the VOMS. > > (later on these are used within extensions of RFC proxies for > attr-authZ) > > > > B. A user contacts a WS-based VOMS with SAML-REQUEST-interface > standard and > > gets a standardized SAML Assertion back signed by the VOMS > service. (later > > on these are used within WS-SecExt within SOAP Headers) > > > > C. A user contacts a Shibboleth system (possibly w/o WAYF) using > SLCs with > > SAML assertions inside its extensions. > > Shibboleth itself does not support SLCs, and you need to develope some > system to issuing SLCs by using Shibboleth as ONE part of this > system. You > can also get SLCs credential through otherway except Shibboleth- > based. IF we > use "push" model, I think how does the client get the credential > doesn'tmatter, what does matter is the content of the credential. Yes, of course, I was referring with Shib to the full palette of it [GridShib, ShibGrid, ***whateverSHIB] I didn't go so much into detail because I hoped Shib* was out of scope here, which in turn means that we do not have to deal with credential formats in that context - my experience is clearly related to GridShib (X.509 + Shib IDP) and rather Globus-driven, which is putting SAML assertions in SLC extensions to be checked by CAS. Q: However, is there precise demand to support Shib from ARC or could this be the non-PGI elements of ARC? Are there users in your production Grid using Shib as AA? Q: What is the plan of EGEE in this context? Are there already users in production using Shib as AA? Info: UNICORE has been enabled with Shibboleth in DEISA, but part of the implementation relies on GridShib to the best of my knowledge following the mentioned approach above. So far - we see no precise demand that Shib-* part should be part of the PGI profile - especially Shib access is not in production in DEISA now, only planned for the next years (-> our of scope of PGI from our viewpoint). > > Futhermore, I can see two different problems here about > interoperability in > PGI in terms of credential/attributes: > a.The interoperability of getting a credential (with attributes > inside); The points you mentioned above are all about this problem. > b.the interoperability of using a credential (with attribute inside). > One user or client (on behalf of user) get the credential, it > needs to > use it and interoperate with services. > > I guess PGI is supposed to solve both of them? I think a might be out of scope since it have to then include proprietary protocols such as classic VOMS?! Part of this discussion is to find this out - maybe there is a way for it?! (e.g. what do you do once your AC-based proxy lifetime ended?! Renewal problem, which interface you use of renewal then?) b. Absolutely! > > > > > > > > D. A user contacts MyProxy with a stored proxy using ACs in its > extension> (implies no new attribute transport mechanism), but > possibly a new > > interface > > of getting (indirectly) attributes. > > > > > > > > > I see the agreement on the elements of this e-mail thread as a > prerequisite> to agree on the mechanisms of which attribute > formats we support and how we > > convey attributes precisely (separate email thread). > > > > ### Possible conclusion: > > > > A. We only reference in our profile possible ways of retrieving > either ACs > > or SAML assertions (e.g. by pointing to the SAML-request > document that is > > in > > public comment currently as mentioned earlier). We do not intend > to profile > > how exactly a user gets its attributes. > > > > B. If we agree on A - we indirectly agree on attribute push > since in the > > attribute pull mode - for interoperability reasons - the > interface of > > getting attributes must be known so that the middleware can > contact it on > > behalf of the user! > > > So we are only going to solve the second sub-problem I concluded > above? Maybe - its actually only my suggestion by now - I'm happy to discuss ways of how we could standardize point (a) mentioned by you. > > > > > > > C. We deal with RFC ACs > > Not VOMS AC? Please provide a reference for this standard. > > > > > > > > D. We deal with SAML assertions > > > > E. We only consider C+D in the first iteration of the profile > > > > > > > > ### open Questions > > > > Q: Can we agree on these conclusions? Are there any comments - > something I > > missed? > > Changing VOMS AC to RFC AC? > Plus Supporting SAML Assertion? That is the input for the next e-mail thread then - which types of attribute transport formats we have to support - I guess that's hopefully all of them, while hopefully avoid using SAML assertions within X.509 extensions?! > > > > > > > > Q: Is there any production infrastructure that largely supports > Shibboleth> w/o supporting VOMS either in classic or WS style? > > > In terms of ARC, > The production ARC supports VOMS classic > The development ARC supports VOMS classic and WS style, and has it > own SLCs > service which is based on Shibboleth IdP. ok - useful information - the question would be then when you plan to move from development to production with the WS-style? Nevertheless, we have to support VOMS Classic since Steven stated clearly that EGEE will not directly move soon to the WS-style - and even if they do - there would be probably a lot of services that will be only Classic VOMS compliant. > > Cheers > Weizhong Thanks for your sharing your thoughts! > > > > > > > > > > > > > Please consider the attribute - and its transport mechanisms out > of scope > > in > > this e-mail thread. > > > > > > 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) > > > > > > > > _______________________________________________ > > Pgi-wg mailing list > > Pgi-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/pgi-wg > > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

Re: [Pgi-wg] Sec: Agreement on supported AttributeAuthorityInterfaces
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Hi Steven, exactly - I just want to find out if we can agree on classic VOMS & SAML VOMS "attribute packages" or if we have to support a third "attribute package" maybe coming out of the [Shib*,GridShib,ShibGrid] field. They are all slightly different "attribute packages". Once we found that out - we going after the question how the packages are presented to the services. 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: Steven Newhouse <Steven.Newhouse(a)cern.ch> Date: Thursday, March 19, 2009 9:22 pm Subject: RE: RE: [Pgi-wg] Sec: Agreement on supported Attribute AuthorityInterfaces > > I think standardization of the Classic AC VOMS interface is out of > > scope while the standardization of the SAML-based VOMS interface is > > done by SAML. > > I'd agree - just wanted to check! > > > But we should state in the document both as examples of > > retrieving attributes to get the profile more clear. > > They are both valid scenarios... surely we only need to profile the > attributes and how they are packaged and presented to the service? > Or am > I missing something? > > Steven > ------------------------------------------------------------------- ------------------------------------------------------------------- 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

modified plan for jobmanagement discussions
by Balazs Konya 19 Mar '09

19 Mar '09

Dear All, During the last teleconference a suggestion to speed up the PGI process was made. It was proposed to start weekly phone meetings (on Wednesdays) to discuss the computational related topics. Andrew volunteered to chair the first meeting and provide a summary of the available documents related to computation (http://forge.gridforum.org/sf/docman/do/listDocuments/projects.pgi-wg/docma…) Since then, the PGI co-chairs have been discussing and reconsidering whether this would really be the most efficient approach, i.e. start a discussion around the interpretation of raw drafts. The jobmanagement related drafts are the results of both the pre-OGF work of the ARC/gLite/Unicore teams and the work undertaken in the GIN community group. The drafts in their current status are rather difficult to be interpreted correctly since they were not meant to be for public consumption, they were written as internal working materials for a smaller group. Since then, we never had the time to put these documents in a more readable form. Thus, we feel that it is our responsibility to first better organize our initial drafts, so that people can make better use of their time by reading the improved document rather than trying to "reverse engineer" our ideas from the current poorly written notes. Therefore, we concluded that the PGI group would make a better progress if the proposed modified plan was followed: 1) the initial authors of the drafts are asked to re-work their internal memos, create a consistent write-up of their ideas, prepare a draft about the "production execution service". This document on "production execution service" should describe all the main aspects of a job management service needed in a production environment. Proposed deadline for the document: 31st March 2) schedule the first jobmanagement phone conference one week after the write-up is available: initially on 8th April. This also means that the teleconference called for this Wednesday is not needed. 3) meanwhile, the security discussions should go forward with full speed and hopefully result in an agreed draft. regards, Balazs, Moreno, Morris PGI co-chairs

7 9

Re: [Pgi-wg] Sec: Agreement on supported Attribute AuthorityInterfaces
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Hi, sorry for the confusion - the goal is here simply to find out if there are other ways in infrastructures except [SAML-based VOMS, classic AC VOMS, Shibboleth] to retrieve attributes and if we may can skip the need for Shib* ways of doing it. I think standardization of the Classic AC VOMS interface is out of scope while the standardization of the SAML-based VOMS interface is done by SAML. But we should state in the document both as examples of retrieving attributes to get the profile more clear. I got from the mail of you about EGEE (I refered to in my mail) that we have to support Classic AC VOMS, which in turn means to look closer on the "AC embedded proxy" approach in our profile (other upcoming e-mail thread). You may see it as a precondition before looking closer to the precise encoding of transport mechanism. Hope that helps, 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: Steven Newhouse <Steven.Newhouse(a)cern.ch> Date: Thursday, March 19, 2009 3:55 pm Subject: RE: [Pgi-wg] Sec: Agreement on supported Attribute Authority Interfaces > Hi Morris, > > I'm confused by the context here... are you suggesting we look to > standardise the VOMS interface (or the service that serves up the > proxy that) or the proxy and its content itself? > > Thanks, > > Steven > > Dr Steven Newhouse > EGEE Technical Director > http://cern.ch/Steven.Newhouse > > > > -----Original Message----- > > From: pgi-wg-bounces(a)ogf.org [pgi-wg-bounces(a)ogf.org] On Behalf > > Of Morris Riedel > > Sent: 19 March 2009 14:22 > > To: pgi-wg(a)ogf.org > > Subject: [Pgi-wg] Sec: Agreement on supported Attribute Authority > > Interfaces > > > > Hi PGI security folks, > > > > another issue I see is the supported attribute authorities and > (more> notably) their interfaces. > > > > Taking our experience from GIN into account and addressing the > message> of Steven (EGEE) there are still two interfaces to > consider in terms of > > VOMS. > > Also, as an alternative AA there is Shibboleth quite much used > in the > > space. > > > > ### goal > > > > (a) > > We are discussing which AA can be used in PGI to retrieve > attributes...> > > (b) > > ...because we want to find out which interfaces have to be > supported to > > get attributes... > > > > > > (c) > > ... in order to know more precisely which types of attribute > transport> mechanisms we have to support in PGI. > > > > ### Possible scenarios > > > > A. A user contacts a non-WS-based classic VOMS with a proprietary > > interface, but gets a standardized RFC AC back with the attributes > > signed by the VOMS. > > (later on these are used within extensions of RFC proxies for > attr- > > authZ) > > > > B. A user contacts a WS-based VOMS with SAML-REQUEST-interface > standard> and gets a standardized SAML Assertion back signed by > the VOMS service. > > (later on these are used within WS-SecExt within SOAP Headers) > > > > C. A user contacts a Shibboleth system (possibly w/o WAYF) using > SLCs> with SAML assertions inside its extensions. > > > > D. A user contacts MyProxy with a stored proxy using ACs in its > > extension (implies no new attribute transport mechanism), but > possibly> a new interface of getting (indirectly) attributes. > > > > > > I see the agreement on the elements of this e-mail thread as a > > prerequisite to agree on the mechanisms of which attribute > formats we > > support and how we convey attributes precisely (separate email > thread).> > > ### Possible conclusion: > > > > A. We only reference in our profile possible ways of retrieving > either> ACs or SAML assertions (e.g. by pointing to the SAML- > request document > > that is in public comment currently as mentioned earlier). We do not > > intend to profile how exactly a user gets its attributes. > > > > B. If we agree on A - we indirectly agree on attribute push > since in > > the attribute pull mode - for interoperability reasons - the > interface> of getting attributes must be known so that the > middleware can contact > > it on behalf of the user! > > > > C. We deal with RFC ACs > > > > D. We deal with SAML assertions > > > > E. We only consider C+D in the first iteration of the profile > > > > > > > > ### open Questions > > > > Q: Can we agree on these conclusions? Are there any comments - > > something I missed? > > > > Q: Is there any production infrastructure that largely supports > > Shibboleth w/o supporting VOMS either in classic or WS style? > > > > > > > > > > Please consider the attribute - and its transport mechanisms out of > > scope in this e-mail thread. > > > > > > 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) > > > > ------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------

2 1

Sec: New directory for strawman from Catania
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Hi security folks, I put the strawman document as discussed earlier into the input section since it not reflects a draft we agreed on: http://forge.gridforum.org/sf/go/projects.pgi-wg/docman.root.input_document… I also put my commented version close to it - but of course it makes more sense to discuss many issues with it rather on the list or at the telcon tomorrow. Nevertheless - Duane might find some comments interesting to get easier into discussions on target tomorrow. Even if there is a lot of "stress" around the document - we also have to thank Duane for the work. Many items of it are useful (SAML, VOMS AC, etc.) and others have to be discussed and maybe revised (EPR with hundreds of VOs in it in the metadata section). I hope we all can get still to an agreement, which is the highest motivation of PGI. Finally, I encourage all the PGI security experts of being part of the discussions tomorrow while working on the e-mail threads we have established. Your co-chair, 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