You *have* to support WS-Addressing in order to leverage the BES spec. Why are you (re)defining endpoint properties in GLUE instead of re-using existing ways of describing the same in EPR documents? -Duane 2009/3/27 Morris Riedel <m.riedel@fz-juelich.de>
Hi team,
So in my mail from yesterday evening, I referred again to the plumbings and before I will draft now slides/factsheets I would like to shortly point out again what I mean with it - maybe more explicitly - although this has been already discussed with several AuthZ specialists in prior OGFs or other events (e.g. Valerio Venturi, etc.).
Major idea: Simple + Stupid - not cracking the security dilemma, but creating a significant step towards DEFINING the common security models/plumbings:
# First of all, the clients choose the client technology they like or find convenient for their science (maybe even business) - I think that's something where we all agree to.
###### 1 - Pluming Type: Authentication (either-or)
= TWO choices here: PGI_AUTHN_ENDENTITY or PGI_AUTHN_PROXIES (meaning one has to support the chain checkings)
# an end-user uses this client with an PGI out-of-band mechanism (maybe LDAP queries) to retrieve GLUE-based information about a certain endpoint getting:
# endpoint contact information (i.e. BES URL) AND
# GLUE SECURITY.AUTHENTICATION capability of this endpoint
# The value of this capability is either PGI_AUTHN_ENDENTITY or PGI_AUTHN_PROXIES
# The client know how to contact the endpoint on the TLS level then, which is in PGI the foundation for AUTHN
###### 2 - Plumbing Type: Attibute-based AuthZ (at least one of it)
= TWO choices here: PGI_AUTHZ_AC or PGI_AUTHZ_SAML
# an end-user uses his client again (or retrieved information with the first request) with an PGI out-of-band mechanism (maybe LDAP queries) to retrieve GLUE-based information about a certain endpoint getting:
apart from the above information:
# GLUE SECURITY.AUTHORIZATION capability of this endpoint
# The value of this capability is AT LEAST ONE of PGI_AUTHZ_AC, PGI_AUTHZ_SAML - maybe even both
# The client knows how the attributes have to be transported to the endpoint then so that the endpoint understands them and uses them for attr-authz based on resource-owner policies.
#### The bottom line is that we just have to define a few bits and pieces precisely that are PGI_AUTHN_ENDENTITY, PGI_AUTHN_PROXIES , PGI_AUTHZ_AC, PGI_AUTHZ_SAML. Each of it well-defined with respect to used standards, IETF RFCs, OASIS SAML, like Etienne listed...
With that we significantly narrow down the possibilities in terms of security while we have two different types of plumbings that are easy to understand: AuthN + Attr-AuthZ.
Maybe we need another plumbing because of the difference of using the incompatible general proxies and GSI proxies on the TLS level, but both are part of the AuthN plumbing type. Maybe in future this incompatibility is fixed and then one plumbing might be just removed without changing standards.
### Looking from the end-user point of view seeing a united federation of Grid systems, the user uses his client that may only support one plumbing in terms of attr-AuthZ . In that matter the client only queries from the out-of-band-information service GLUE-described endpoints that only supports these systems that match with the supported plumbings from the client (and matched other requirements like cores/memory/interconnection of course).
Of course, we have to agree on the transported attribute structure - but the deployment of plumbings is policy of the respective infrastructures. The infrastructures may even setup two endpoints with different plumbings to support more clients that is still better than having a complete middleware co-existence at the resource level...
Hence, the idea of the plumbings was to have a relatively easy to understand mechanism to describe what end-user clients require to understand when performing interoperability use cases. Also, as you see in my figures, the security plumbings are close to the information plumbing (i.e. GLUE) meaning that both have to be installed in a working house.
I hope the idea of plumbings got much clearer now, but I will try to provide some figures for the telcon this afternoon. Like the reference model term, also the plumbings term can be changed to something more understandable.
Of course, the plumbings are only my suggestion coming from GIN interop. use case experience and working in the field of interop for many years now - of course its still subject to discussion - but it has much potential to bringing us closer together NOW instead of waiting for a huge common security framework in the future that may not even be defined (+deployed!) before the Grid fundings are stopped...
Finally, with looking from a slightly distance on the group, I'm happy that we are still in the process of jointly discussing in the group and no one leaves and thus I'm confident that we can act as a team to provide something useful to the Grid community, which is maybe not the perfect solution in terms of security, but a good step forward bridging different worlds - achieving interoperability at least between several Grid islands...
Your co-chair, 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)
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg