[Pgi-wg] More information on Security Plumbings (with GLUE dependencies)

[Morris Riedel]

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 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)

-------------- 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/20090327/adc0fe16/attachment.bin