[Pgi-wg] Sec: Agreement on SOAP and authentication

Thu Mar 19 12:40:14 CDT 2009

Duane,

  in addition I forgot to mention that we already agreed in PGI that we only do attribute-based authorization for those that would like to be PGI-compliant while still supporting identity-based authZ of course.

It's not related here for AuthN - but helps to understand my circumvention of the complicated 'additional' scope. It makes sense - but allows too much flexibility I think that break possibly interop again.

You may want to support still purely identity-based authZ in the non-PGI-compliant part. At least that is my suggestion. Otherwise we end up of standardizing each functionality purely out of our systems.

Sorry for not mention that again,
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 at 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: Duane Merrill <dgm4d at virginia.edu>
Date: Thursday, March 19, 2009 2:40 pm
Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication

> I don't understand the strict "either-or" wording below with 
> regards to PCs
> versus PKCs in a *proxy-plus-embedded-AC* conformance target.  You 
> make it
> sound like their use would be unilaterally mutually exclusive.  
> Both types
> of certificates can embed attribute certificates, and there is an
> "is-a"/polymorphic relationship here: a PKC is a PC of delegation 
> depth zero
> (and therefore does not have the extension OID set).
> 
> A *proxy-plus-embedded-AC* conformance target should describe
> implementations that allow both.  In the strawman document, the 
> goal of
> layering the *pgi-tls-proxy* conformance target on top of the
> *pgi-https*target was to add functionality (not take it away):
> *pgi-tls-proxy* describes SOAP implementations that perform mutual 
> SSL/TLSauthentication with certificates, and these certificates 
> MAY have proxy
> extensions (making them PCs) and MAY have AC extensions (embedding 
> attributecertificates).
> 
> Perhaps I am just misinterpreting your language.
> 
> -Duane
> 
> 2009/3/19 Morris Riedel <m.riedel at fz-juelich.de>
> 
> > 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 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)
> >
> >
> >
> > _______________________________________________
> > Pgi-wg mailing list
> > Pgi-wg at 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
-------------------------------------------------------------------
-------------------------------------------------------------------