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

Sec: Agreement on SOAP and authentication
by Morris Riedel 19 Mar '09

19 Mar '09

Hi security folks, reading certain elements of the IIRM, strawman, and following discussions on the list - I see there is still no common agreement on SOAP / HTTP(S) in some areas. ### Goal: (a) We are discussing if SOAP / HTTPS can be used in PGI to contact a functional interface (like BES)... (b) ...because we want to find out if there is any important service in the PGI context that is not capable of using SOAP (over SSL layer)... (c) ... in order to find out if we can agree on SOAP/HTTPS or to understand requirements from other non WS-based interfaces in PGI. Therefore the aim of this thread is to get to an agreement in this context, while considering Attribute authorities like VOMS as a supportive service and not an functional interface (also separate thread). ### Contacting functional implementations with SOAP If we consider the case that we communicate with an functional interface like OGSA-BES - we agree on SOAP. ### TLS/SSL Layer: # <strawman> Foundational: 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). # </strawman> # <simple plumbings: authentication> We use authentication either based on identities inside X.509 end-entity public key certificates or X.509 proxies (including restrictions, encoding handled separately in another thread). This refers of using either one or the other of these certificate types on the SSL/TLS level. For simplification of the profile - there should be no direct dependencies with attribute-transport used for authorization. # </plumbings> ### Possible scenarios: # A. TLS with end-entity certificate, SOAP in message -> authN check with CA # B. TLS with (restricted) proxy certificates, SOAP in message -> authN check with proxy signer chain ### Possible Conclusion: # We use SOAP inside a message to contact functional interfaces. # We use either full X.509 end-entity certificates OR X.509 proxies (with restrictions) ### Open Questions: Q: There are WS interfaces for functional specifications that matter to PGI (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP based on HTTPS as mentioned above? Q: If not - are there any important functional interfaces (except support interfaces from AAs like classic VOMS) that do not support SOAP in the PGI ecosystem? Please feel free to comment but let the question of attributes+restrictions outside - I propose to deal with it in separate threads because of their complexity. 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)

1 0

Cracking security by small agreement pieces
by Morris Riedel 19 Mar '09

19 Mar '09

PGI Security folks, in my opinion we crack the security better if we try to come to agreements on smaller pieces first before going to the full-blown profile. Therefore, our next e-mails partially address items from the reference model input (i.e plumbings), the strawman document (provided by Virginia) and other elements that arise from the security discussions via the e-mails. Here, the goal would be to agree on the elements of each e-mail thread. Clearly, tomorrow will be not 'the one and only sec telcon in PGI' therefore we need this mechanism (in my opinion) to give the infrastructures time to comment even if they can't join the telcons or feel being overwhelmed by strawman documents. The agreements on these little pieces will be in turn noted down on the factsheets/wikis/etc one after another creating the whole ecosystem in terms of security. Again, here I would like to remind ourselves that we are the <Production> Infrastructure Working Group - so the security elements should be reasonably stable and adopted and not huge frameworks that MAY arise in future if - and only if - funding is provided. So let's get started... 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)

1 0

Use Case Document on Gridforge (in odt and doc)
by Morris Riedel 19 Mar '09

19 Mar '09

Hi PGI folks, as promised earlier, I just created a doc version and uploaded it on GridForge. Both are located at: http://forge.gridforum.org/sf/go/projects.pgi-wg/docman.root.input_documents .use_cases Please feel free to comment on this use case. 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)

1 0

Documenting the security agreement/info progress
by Morris Riedel 19 Mar '09

19 Mar '09

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)

1 0

F2F workshop anybody?
by Oxana Smirnova 19 Mar '09

19 Mar '09

Hi all, after digesting all the threads, I came to a conclusion that we'd need more F2F workshops like the one at CERN. There was even an idea to have one before OGF25, but it didn't work because many didn't feel like doing transcontinental trips too often. Now that OGF25 is behind, shall we find a good date and place for an F2F session? Lund is best in spring and is nicely located 50km away from the Copenhagen airport; alternatively, NDGF premises are located 800 meters from the above mentioned airport. Cheers, Oxana

4 3

PGI TelCon 2009-03-13 Meeting Minutes available for Comments
by m.riedel＠fz-juelich.de 19 Mar '09

19 Mar '09

Hi PGI team, as having no secretary today I drafted (not necessarily complete) minutes, which are available in GridForge: http://forge.gridforum.org/sf/discussion/do/listPosts/projects.pgi-wg/discu… Please feel free to comment on the miuntes. More precise actions in preparation for the telcons will follow ASAP. 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 ------------------------------------------------------------------- -------------------------------------------------------------------

7 15

Re: [Pgi-wg] Discussion about elements/priorities in the field ofsecurity
by m.riedel＠fz-juelich.de 18 Mar '09

18 Mar '09

Howdy partners, (1a) > > If we are talking about attributes carried inside SAML > assetion, getting > > the attributes from attribute authority is not a challenge, for > instance we > > can use the VOMS SAML service (client gets back SAML assertion that > > including attributes through SSL authentication with VOMS SAML > service) as a > > candidate. Well I propose that we MAY have to consider also the classic VOMS style in using the Proprietary VOMS protocol to obtain ACs, because of interoperability reasons since many of our infrastructures (i.e. ARC + EGEE) rely on this - or am I wrong in this? Please consider that we have to focus on production not what may arise in 2 years time as a security framework. More conrete facts/questions: GENESIS-II and UNICORE will work with SAML-based VOMS because of largely build in support for SAML assertions. Q: Is there a short-time plan that ARC will be able to support SAML-based VOMS? Q: Is there a short-time plan that gLite will be able to support SAML-based VOMS? (1b) > I propose that the "aquisition of tokens" in a push-style model is > orthogonal to action-item (1). If we want to consider it, we > should address > it as a separate concern (in the same vein that > aquisition-of-delegation-tokens has been broken out into a > seperate issue). > Action-item (1) should be about nothing more complicated than > profiling a > simple request-response message exchange between two endpoints in > which all > parties already possess the necessary credentials. I agree with Duane - having both discussed together is too complex and certain elements of it are also part of a security document which in OGF public comment I guess: https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.ggf-ed… I suggest that we... a) create for this a seperate number in the thread which is 6 then b) re-use elements of the security groups we are working with, i.e. the above mentioned document and others. (1c) > > But how to push the SAML assertion from client side to service > side could > > be a challenge (for which voms has not provided solution, IMO). > I can see > > two ways: one ways is put the SAML assertion into X.509 proxy > certificate's> extension, by which you can gurantee that the > attributes information is > > binded with SSL authentication; > > > > I believe that the use-case for attribute-bound SSL authentication > involvesX.509 attribute certs (ACs) as per the original VOMS > implementation rather > than SAML attributes. > > > > the other way is to put SAML assertion in the SOAP header, which > > furtherly cause two branches: First brach, using the SAML > assertion for > > message (SOAP) level authentication + attribute carraying (in > this case the > > VOMS SAML service should probably be improved to creat SAML response > > containing a holder-of-key authentication assertion, then this > assertion can > > be used for message level authentication according to WS- > Security SAML Token > > profile 1.1); Second branch, using SAML assetion only for attribute > > carraying (in this case, the transport level securiry should be > configured).> I have been contributing to the SAML-based VOMS via OMII-Europe by being the first using it...:-) So the idea in 2006 was to use WS-Security Extensions in SOAP Headers with n SAML Assertions. CAS of Globus works with SAML assertions inside proxies to largely support Shibboleth and SLCs. However here I would strongly disagree to put this into PGI. I know no infrastructure using it directly like that. (2) > Yes. The Strawman doc makes an initial stab at this by profiling a > FQAN-style syntax/semantics for both X.509 ACs and SAML > assertions. (VOMS > already does that for the former, and the SAML examples in Morris' > doc in > GridForge resemble the latter.) That way both assertion-styles > would be > capable of conveying identical information. Yeah - but of course, we should explicitly make a list and come to an agreement between all of our members. So, it looks we have identified the security experts from GENESIS-II, ARC, and UNICORE - so we could need an expert of gLite too for Friday. Thanks for sharing your thoughts. Take care, Morris ----- Original Message ----- From: Duane Merrill <dgm4d(a)virginia.edu> Date: Tuesday, March 17, 2009 4:29 pm Subject: Re: [Pgi-wg] Discussion about elements/priorities in the field of security > Comments inserted.... > > 2009/3/17 weizhong qiang weizhongqiang(a)gmail.com > > > > > If we are talking about attributes carried inside SAML > assetion, getting > > the attributes from attribute authority is not a challenge, for > instance we > > can use the VOMS SAML service (client gets back SAML assertion that > > including attributes through SSL authentication with VOMS SAML > service) as a > > candidate. > > > > I propose that the "aquisition of tokens" in a push-style model is > orthogonal to action-item (1). If we want to consider it, we > should address > it as a separate concern (in the same vein that > aquisition-of-delegation-tokens has been broken out into a > seperate issue). > Action-item (1) should be about nothing more complicated than > profiling a > simple request-response message exchange between two endpoints in > which all > parties already possess the necessary credentials. > > > > But how to push the SAML assertion from client side to service > side could > > be a challenge (for which voms has not provided solution, IMO). > I can see > > two ways: one ways is put the SAML assertion into X.509 proxy > certificate's> extension, by which you can gurantee that the > attributes information is > > binded with SSL authentication; > > > > I believe that the use-case for attribute-bound SSL authentication > involvesX.509 attribute certs (ACs) as per the original VOMS > implementation rather > than SAML attributes. > > > > the other way is to put SAML assertion in the SOAP header, which > > furtherly cause two branches: First brach, using the SAML > assertion for > > message (SOAP) level authentication + attribute carraying (in > this case the > > VOMS SAML service should probably be improved to creat SAML response > > containing a holder-of-key authentication assertion, then this > assertion can > > be used for message level authentication according to WS- > Security SAML Token > > profile 1.1); Second branch, using SAML assetion only for attribute > > carraying (in this case, the transport level securiry should be > configured).> > > The second branch you describe ("bearer" style) is not viable: you > need a > "holder-of-key" approach in which the caller demonstrates > possession of a > private key corresponding to the public one signed into the > attribute by the > attribute authority. (You could potentially demonstrate this via > an SSL > signature, but I consider that to be an ugly hack and explicitly > discouragedit in the Strawman document.) > > Thus we arrive at two scenarios: ACs-via-SSL-authn and SAML-via- > SOAP-authn. > Confidentiality and integrity provided in both cases by SSL/TLS, > of course. > > > > > (2) Agreement on Definition/Semantics/Structure of Attributes > > > > > > Yes. The Strawman doc makes an initial stab at this by profiling a > FQAN-style syntax/semantics for both X.509 ACs and SAML > assertions. (VOMS > already does that for the former, and the SAML examples in Morris' > doc in > GridForge resemble the latter.) That way both assertion-styles > would be > capable of conveying identical information. > > Cheers, > > Duane > ------------------------------------------------------------------- ------------------------------------------------------------------- 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] Scientific Computing - Integrating Service and Desktop Grids - Standardization
by Etienne URBAH 18 Mar '09

18 Mar '09

Jesus, Thank you for your study on my proposal to use Restricted Proxies permitting that untrusted computing resources from Desktop Grids have restricted access to storage resources of Service Grids. Compared to the current situation of unrestricted proxies which could be completely revoked, I do NOT understand how embedded read/write attributes could trigger any NEW revocation issue. EDGeS is also actively working on data storage by Desktop Grids. In particular, XtremWeb already provides it. The whole security model still has to be defined, and must be thoroughly reviewed. AFAIK, our EDGeS project considers that each Cloud provider has created its own closed proprietary environment and refuses any interoperability, so we are NOT planning to work about interoperability with Clouds. For video conferences, our MCU server is ccmcu40.in2p3.fr But I have NOT planned a video conference yet. Please note that the OGF26 date has changed : - OGF26 (Chapel Hill, NC, USA) 26-29 May 2009 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 Wed, 18 Mar 2009, Jesús Luna wrote: > Dear Etienne, > > First of all I'd like to excuse myself for this late reply to your email, however I'd like to let you know that there has been a change in my affiliation and since February I'm working with Barcelona Digital (an R+D center located in Barcelona, Spain). Nevertheless I still keep my interest in participating with EDGeS, in particular when referring security/privacy aspects. > > I've reviewed your proposal about potential use of Restricted Proxies and IMHO it's a nice approach for solving part of the trust issues that arise when bridging Service+Desktop Grids, however I'd like to comment the following: > > -A mechanism able to provide up-to-date Restricted Proxy's validation at the Trusted Node might be required to avoid potential security gaps related with the propagation of revocation information (i.e. updating read/write attributes or even revoking the whole Proxy). This issue was studied at OGF's CAOPS WG a couple of years ago (in fact I was part of that WG). > > -As a CoreGRID fellow, last year I was researching potential use of Desktop Grids for storing data (something I called a Desktop Data Grid). A paper was presented at the PCGrid'08 workshop (I met Peter there). Are you considering also this potential use as part of EDGeS project? If so, then we should review the proposed approach as Storage Nodes would be untrusted in this new scenario. > > -Finally, are -EDGeS- you planning to do some work about Cloud+Desktop Grid's interoperability? Maybe a position paper? > > Thanks again for taking into account my opinion and please keep me informed about forthcoming videoconferences. > > Regards, > > JESUS LUNA GARCIA > Security Researcher > M. 618 213 212 > jluna(a)bdigital.org > BARCELONA DIGITAL CENTRE TECNOLOGIC > Sancho de Avila 110-130, 08018 Barcelona > Tel. 93 553 45 40 - Fax. 93 553 45 41 > www.bdigital.org > > > > > > >> -----Mensaje original----- >> De: Etienne URBAH [mailto:urbah@lal.in2p3.fr] >> Enviado el: miércoles, 28 de enero de 2009 17:32 >> Para: J. LUNA >> CC: Peter KACSUK; Oleg LODYGENSKY; edges-na3(a)mail.edges-grid.eu >> Asunto: Scientific Computing - Integrating Service and Desktop Grids - >> Standardization >> >> Hi Mr. LUNA, >> >> >> In the domain of scientific computing, I am working with Peter KACSUK >> of MTA SZTAKI (Budapest, Hungary) inside the EDGeS project >> http://www.edges-grid.eu/ which is bridging >> Service Grids (Production Grid Infrastructures, like EGEE) with >> Desktop Grids (loose opportunistic grids using idle resources, like >> BOINC, XtremWeb, OurGrid). >> >> For the rationale, you can look at the text at the bottom of this mail. >> >> >> By now, our project, and other projects listed below, provide bridges >> in real operation between Service Grids and Desktop Grids. >> >> In order to provide world wide support of the growing computing needs >> of scientific communities, it is now time to : >> - bring together the existing projects bridging existing Services >> Grids and Desktop Grids, >> - begin the standardization of the integration of existing Services >> Grids and Desktop Grids. >> >> >> Therefore, we would like to work inside OGF PGI (Open Grid Forum - >> Production Grid Infrastructure) >> http://www.ogf.org/gf/group_info/view.php?group=pgi-wg so that the OGF >> recommendations take into account the bridging of Desktop Grids, in >> particular the issues about Information representation, Security, Job >> submission and Monitoring. >> >> For information about relevant OGF standards, you can look at David >> WALLOM's excellent presentation 'Standardisation: Recent progress >> review and best-practices sharing: Middleware Track', in particular >> pages 27, 28 and 30, at >> http://www.beliefproject.org/events/econcertations/6th- >> econcertation/ppts/eConcert-Standards-Middleware-track.pdf >> >> >> We have to make the best use of, and perhaps improve GLUE2, AUTHZ, >> BES, JSDL, SRM, ... >> >> In particular, the current work of OGF PGI about 'Restricted >> Impersonation' could permit that untrusted computing resources from >> Desktop Grids would have access to storage resources of Service Grids : >> see my presentation at >> http://forge.gridforum.org/sf/go/doc15450?nav=1 >> >> >> Among others, we are inviting following projects for the >> standardization of 'Integrating Service and Desktop Grids' : >> - BOINC (University of Berkeley) >> - LATTICE (University of Maryland) >> - EELA-2 OurGrid (INFN, Italy - Universities, Brazil) >> - CONDOR backfill (University of Wisconsin) >> - Superlink (Technion, Haifa) >> - Clemson Campus Grid (Clemson University) >> >> We have H323 equipment permitting direct video communication, and we >> could use the EVO facility at http://evo.vrvs.org/evoGate/ for video >> conferences. >> >> We are willing to work actively and present our progress at : >> - OGF25 (Catania, Italy) 02-06 March 2009 >> - OGF26 (Chapel Hill, NC, USA) 08-12 June 2009 >> - OGF27 (Bannf, Alberta, Canada) 12-16 October 2009 >> >> >> For more information about EDGeS, you can look at my presentation >> 'EDGeS : Bridging EGEE to BOINC and XtremWeb' at >> http://forge.gridforum.org/sf/go/doc15437?nav=1 >> >> >> Thank you in advance for your comments on 'Restricted Impersonation' >> and for your participation. >> >> >> 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 >> ----------------------------------

1 0

Definition of a Production Grid
by Laurence Field 17 Mar '09

17 Mar '09

Dear All, The word Grid means different things to different people and this quite frequently leads to misunderstandings and conflict. This is especially true within OGF where people from many different domains and backgrounds discuss "Grids". While each and every definition themselves are as valid as each other, trying to discuss a concept from two possibly unrelated perspectives is quite difficult. Before we move forward in the PGI activity we therefore need understand what we mean by "Grid" and hence the problem we are trying to solve. It seems that in some recent threads the word "production" has cause some disagreements as this word is more commonly used to reflect quality rather than concepts. From my perspective I can try to define the core properties that I see are key when describing the EGEE infrastructure. I would hope that similar infrastructures with whom EGEE would like to interoperate would have a similar description. I would like to introduce the term "Muti-institutional infrastructures for e-Science" which can be used to describe something with the following properties. 1) Multi-institutional. The EGEE infrastructure is composed by linking resources that reside at autonomous academic institutes. The key concept here is the administrative domain which maps to a real institute and that there is more than one institute in the infrastructure. 2) The Virtual Organization The main aspects that links these institutes is the drive to collaborate in order to do science. The collaborations are defined by Virtual Organizations. 3) x509 Certificates and Proxies Users are identified by x509 certificates which are provided by CAs accredited by the IGTF. Proxies are typically used to interact with services. 4) VOMS To identify which VO a user is belong to is by contacting VOMS. VOMS also supports Roles an Groups within the VO which is implemented by adding attributes to the proxy. 5) Multiple Services The are many different types of services each of which can define their own interfaces which may or many not be a Web Service. 6) Parrallel Information System The information about services is found by querying an information system which is not necessarily related to the service interface. 6) Scale 100s of administrative domains, thousands of users, thousands of services, millions of computing actives and petabytes of data. This may be a can of worms but if we can agree on a set of properties for what we mean by "Production Grid" it might help in the discussions. I don't mean that anything that has different properties is not a production grid, I just want to clarify what this group mean when it talks about a Grid infrastructures. Laurence Laurence

8 18

Re: [Pgi-wg] Discussion about elements/priorities in the field of security
by Duane Merrill 17 Mar '09

17 Mar '09

I would suggest that at some stage we also reference some of the aspects of communication that would be necessary for profiled interop, but that we've been assuming as givens, i.e SOAP over HTTP. Perhaps in (1). Duane On 3/17/09, Morris Riedel <m.riedel(a)fz-juelich.de> wrote: > Hi PGI security folks, > > > currently I see five major elements in terms of security related to PGI: > > > (1) > Authentication/Attribute-based Authorization (i.e. plumbings as named > earlier), maybe first push-based before looking at pull-based models - > although, this of course, can be discussed as well among us. > > > (2) > Agreement on Definition/Semantics/Structure of Attributes > > > (3) > Encoding of delegation restriction/constraints > > > (4) > Interface of delegation service (maybe based on subset of WS-Trust) > > > (5) > Agreement on third party credentials transportation (e.g. a delegated > GridFTP proxy/SAML assertion-based access for data-staging during BES > submissions) > > > As a starting point - have I forgot something in this enumeration? If so - > please answer to this thread. > > > In terms of priorities, I would suggest to focus first on number one, but of > course feel free to comment within this thread. > > > Your co-chair, > Morris > > P.S. I cc'ed the area director of security (David Groep) to ensure that we > did not duplicate efforts done elsewhere (i.e. in the OGSA-AuthZ group). We > have been in touch about a few security issues raised in GIN earlier. CIAO. > > > ------------------------------------------------------------ > 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) > > >

1 0