[Pgi-wg] Sec: Ways of specifying the security plumbings

[Morris Riedel]

Hi PGI team,

  looking at the latest conversations I see a demand to discuss how we can
actually profile/specify the security plumbings basically agreed from the
group so far (maybe aligned with information plumbings describing the
security setup).

Unfortunately, there will be no telcon on Friday this week due to eastern
holidays, but next week as usual.

However, we should start a discussion how we can specify the three plumbings
for authN and two plumbings for authZ we agreed on so far.


Addressing the comment from Steven around specifying the GSI elements:

pro
# MWSG means we could specify it although its not a real standard 
# A xyz PGI profile would support our production legacy systems

contra
# we have a PGI profile that includes already elements that are deprecated
(GSI et al.) - plan was to just remove these plumbings over time...
# it's harder to standardize instead of focusing on RFC elements


However, from the most recent work in PGI I got the strong feeling that we
have to stick to the three authN plumbings and two authZ plumbings - maybe
people still disagree here, but I got a response from Alex Sim (SRM
collaboration) mentioning that GSI is still all over the place and non-GSI
versions (i.e. 3.0) will maybe deployed in the next 3-4 years... so out of
scope of our work.


The question arises how we specify these plumbings exactly.


(1) Approach 1 (like WS-RF that consists of n specifications)
# PGI data/job/security (our first document from the charter)
## PGI - AuthN - GSI
## PGI - AuthN - RFCProxy
## PGI - AuthN - EE
## PGI - AuthZ - SAML
## PGI - AuthZ - AC
## PGI - Data - ...

Each of it would be a specification element part of the overall PGI
standard. Adopters refer to it as specifying a server being PGI-AUTHN -
RFCProxy Compliant, etc.


(2) Approach 2 (similar like Duane's approach)
We define everthing in one specification and combine our elements with
# MANDATORY to support at least one of...
# MANDATORY to support ...or / and
# etc. 

Here adopters refer to Tags like PGI_COMM_XYZ within the PGI specification
to indicate whether a system supports proxies or not.


Any other approach I missed?


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 at 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 at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
>-Steven Newhouse
>-Sent: Wednesday, April 08, 2009 8:02 AM
>-To: Etienne Urbah; aleksandr.konstantinov at fys.uio.no; Duane MERRIL; pgi-
>-wg at ogf.org
>-Cc: edges-na3 at mail.edges-grid.eu; lodygens at lal.in2p3.fr
>-Subject: Re: [Pgi-wg] OGF PGI - Security Model - NEW versions of GSI
acceptRFC-
>-3820-compliant X509 proxies
>-
>-Etienne raises a valid point...
>-
>-> Important is that old versions of GSI, which do NOT accept RFC-3820-
>-> compliant X509 proxies, block interoperability, and are then STRONGLY
>-> DEPRECATED.
>-
>-These are still being used and supported (to provide legacy
>-compatibility) but alongside support for the newer X509 proxy system.
>-
>-> Therefore, each provider of grid middleware using such an old version
>-> of GSI :
>-> -  MUST establish and publish the list of the components which still
>-> uses it,
>-> -  SHOULD migrate to a new version of GSI which also accepts RFC-3820-
>-> compliant X509 proxies.
>-
>-This group has no right to mandate what middleware providers should or
>-should not do! But if no provider is JUST using old versions of GSI and
>-intend to migrate away from them I see no point in trying to define a
>-profile around something that has no clear specification (just the GT
>-implementation) and everyone intends to remove in the future.
>-
>-Surely its better to focus our energies on defining a profile around the
>-new style proxies that groups intend to support going forward?
>-
>-Steven
>-
>-_______________________________________________
>-Pgi-wg mailing list
>-Pgi-wg at ogf.org
>-http://www.ogf.org/mailman/listinfo/pgi-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3550 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090408/d8ad3388/attachment.bin