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. Thanks, 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@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: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Aleksandr Konstantinov -Sent: Friday, March 27, 2009 11:02 AM -To: pgi-wg@ogf.org -Subject: Re: [Pgi-wg] OGF PGI - Security Strawman - -On Monday 23 March 2009 19:57, Etienne URBAH wrote: -> To All, -> -> I thank Duane MERRIL for his 'Profile on Secure Communication' strawman. -> -> But, since today's mail of Vincenzo CIASCHINI asserting interoperability -> between recent versions of OpenSSL and GSI, I do NOT think that -> communication layers are the main isue blocking interoperability. -> -> I propose that instead focusing on communication services, we focus on -> security data defined, on security data transported, and on the -> interpretation of security data by AUTHN/AUTHZ services. -> -> -> So, I propose to criticize following assertions : -> -> -> 1) Grid Users and Certificate Authorities -> ----------------------------------------- -> 1.1) Each grid User is authenticated by a legal body (recognized by a -> government). -> -> 1.2) This legal body uses a Certificate Authority to grant a (long -> lived) X509 certificate to the grid User. -> -> 1.3) Each Certificate Authority is itself or is authenticated by a -> self-signed Root Certificate Authority. -> -> 1.4) All such Root Certificate Authorities trust each other and -> cooperate within APGridPMA, EUGridPMA or TAGPMA (Policy Management -> Authorities). -> -> 1.5) These 3 Policy Management Authorities trust each other and -> cooperate within IGTF. -> -> 1.6) IGTF distributes the list of CA Certificates to be trusted. -> -> 1.7) Each grid Site providing grid Services to grid Users MUST install -> this list of CA Certificates and keep it up to date. -> -> 1.8) Using its X509 certificate, each grid User can create at any time -> a (short lived) X509 proxy with permits impersonation / delegation -> during a short period. -> -> -> 2) Virtual Organizations -> ------------------------- -> 2.1) A Virtual Organization (VO) groups grid Users with common goals. -> A VO is NOT a legal body, can NOT be a Certificate Authority, and can -> NOT issue X509 certificates. -> -> 2.2) Inside DEISA, a Virtual Community also groups grid Users with -> common goals. The relationships between Virtual Communities and Virtual -> Organizations has to be precised by Morris RIEDEL. -> -> 2.3) Each grid User belongs to 1 ore more VO (Virtual Organization), -> which grants him access rights to grid Storage and Computing Ressources. - -I would bery much like to criticize this statement as there will always be some -small user groups or individual users who wouldn't want take care of burden -of setting up a VO. - -> -> 2.4) Access rights are granted by VOs to grid Users through either : -> 2.4.1) VOMS extensions of X509 proxies (this makes a VOMS proxy) -> 2.4.2) SAML assertions -> -> -> 3) Grid Services : Information, AUTHN, AUTHZ -> ---------------------------------------------- -> 3.1) Each grid Infrastucture provides an Information Service, with -> describes the Infrastructure according the the GLUE2 schema. -> -> 3.2) Each grid User can query this Information Service anonymously in -> order to know which security protocol he has to use to submit requests -> to grid Services. - -I disagree with "anonymously". Some infrastructures may rate that information -as confidential. - -> -> 3.3) Each grid User can directly access data hosted by grid Storage -> Services. For Authentication, the grid User can present the public part -> of his X509 certificate or X509 proxy. For Authorization, the grid User -> can present : -> 3.3.1) the public part of his VOMS proxy, or -> 3.3.2) a bag of SAML assertions. - -I see no reason why only these 2 options should be allowed for authorization -decisions. -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. - -> -> 3.4) Each grid User can submit Jobs to grid Computing Services. If -> such a Job needs access to data hosted by grid Storage Services, then -> the grid User must provide a delegation token. This delegation token -> can be : -> 3.4.1) a full VOMS proxy, or -> 3.4.2) a bag of SAML assertions. - -What is "full ... proxy" ? And why only VOMS? Why can't my users use ordinary -proxies? -Or restricted proxies with for example policies embedded (as defined in RFC3820)? - -> 4) Consequences for Interoperability -> ------------------------------------- -> 4.1) X509 proxies MUST fully comply to RFC 3820. -> -> 4.2) VOMS services, which deliver X509 proxies with VOMS extensions, -> MUST fully comply to RFC 3820. -> -> 4.3) The authentication library used by grid Services MUST fully comply -> to RFC 3820 (for example a recent version of OpenSLL), so that it can -> accept as well X509 certificates as X509 proxies. -> -> 4.4) Each grid Site providing grid Services to grid Users MUST install -> files describing VOMS authorizations and other authorizations, and keep -> them up to date. - -What are "files describing ... authorizations"? - -> -> 4.5) The semantics of Authorization tokens MUST be the same for all -> grid Infrastructures : -> 4.5.1) VOMS extensions -> 4.5.2) Restriction attributes -> -> 4.6) The Information Service of each grid Infrastructure MUST describe, -> for each grid Service, which Authorization tokens this Service -> understands (potentially several) : -> 4.6.1) VOMS extensions -> 4.6.2) X509 restriction attributes -> 4.6.3) SAML assertions -> -> 4.7) For SAML assertions, the Information Service of each grid -> Infrastructure MUST describe, for each grid Service, how they are -> transported : -> 4.7.1) As attributes of X509 proxies -> 4.7.2) Inside a SOAP header -> -> Unfinished ... -> -> -> Best regards. -> -> ---------------------------------- -> Etienne URBAH IN2P3 - LAL -> Bat 200 91898 ORSAY France -> Tel: +33 1 64 46 84 87 -> Mob: +33 6 22 30 53 27 -> Skype: etienne.urbah -> mailto:urbah@lal.in2p3.fr -> ---------------------------------- -> -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg