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

[Duane Merrill]

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 at 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090327/d8c4492f/attachment-0001.html