[Pgi-wg] OGF PGI - Security Model

Thu Mar 26 17:16:07 CDT 2009

Hi interop-friends,

 firstly sorry again for missing the last days. I have seen many comments
since then and unfortunately see that the different threads had been united
again mixing things up a bit (maybe it was nevertheless useful).

Finally Steven made a good point with 2-3 sec. models out of n^n ones.

So finally we have reached to the ideas of my suggestions of having
well-defined different security 'plumbings' (aka 2-3 well-defined security
models). I don't care about its precise name...

I just used this term 'plumbings' because it had no pre-definition in
security, please compare the vertical lines in the interoperability
reference model - they are just more simpler defined in terms of AUTHN and
ATTRIBUTE-AUTHZ than the long list presented by Etienne but very much of its
content is the same. I presented this since OGF23&OGF24 within GIN with the
two ways (left AC and right SAML) and the open issues to work on, but never
had chance to write it down in written text yet:

http://www.ogf.org/OGF24/materials/1409/2008-09-16_GIN_SessionTwo_OGF24_Ried
el_v1.pdf

Slide 6 and others... :-)

Especially on this slide 6, even outsiders of our production Grids (like
Chris Smith) understood the meaning of the slide and I got positive feedback
on this from numerous sides.

We all want to reach interoperability here in this group.

We want to do this for certain interop applications. We shouldn't
underestimate the power of the combination of the different security
elements -  nailing down the currently typical ways of using TLS with certs,
Attr-Authz, Attributes, Constraints/Restrictions in conjunction are already
powerful. 

We will have precise PGI definition of aligning such building blocks even if
there are two ways in the end - but there are less than n^n ways that are
currently out there in the security field combining different blocks,
profiles, etc....

Also, what the middleware supports and what is then deployed in turn on
particular production Grids are both different stories!

For instance, UNICORE can be used with the proxy-style (plumbing) enabling
interoperability with gLite, ARC, NAREGI. We have done this for many interop
use cases, for instance with portals requiring proxies.

However, there should be also another full X.509 (plumbing) available where
other common approaches can be used and then expressed correctly via GLUE in
interops as well used other infrastructures with different policies. I even
foresee that there could be used more than one plumbing in parallel.

We may have still single islands in a way - but we also come closer
together, which is a good first step towards the right direction and my
suggestion to move forward in this complex security discussion since its
beginning.

Which particular plumbings of both common approaches are then used in
production Grids is policy of the respective deployments of the middlewares
and may even depend on the underlying interop application use cases which
should be our most significant drivers (!) - BUT the main point is that we
know where we talking about in interop work without having n ^ n different
security setups available!

Only one short example:

# There is one DB with attribute information about of end-users (used by
VOMS)
# Agreeing on the attribute semantics&Structure is important
# VOMS support interface for retrieving AC and also SAML assertions
# There are two ways of transporting the attributes that come out of the
same DB (used for later attr-authZ)
# Both transports have correct AuthN mechanisms (clarifies AuthN+ID-authZ)
# In the end using different plumbings, but the same attributes are then
evaluated against a policy describing maybe having equal policies based on
the same transported attributes of the same DB (re-alignment!)
# In the end what matter are the attributes a user has and what the policy
decides to do with them (if its XACML, ACLs, etc. is unimportant here), but
we should talk about the same things once we evaluate attributes.

I try to provide you more figures, etc. hopefully tomorrow - but on my
slides a lot of it has been already presented numerous times... we just have
to nail it down - but in a more KISS style = Keep in Simple and
Sweet/Stupid!

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)

>------Original Message-----
>-From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
>-Steven Newhouse
>-Sent: Thursday, March 26, 2009 7:16 PM
>-To: Moreno Marzolla; Duane Merrill
>-Cc: pgi-wg at ogf.org; edges-na3 at mail.edges-grid.eu; lodygens at lal.in2p3.fr
>-Subject: Re: [Pgi-wg] OGF PGI - Security Model
>-
>-> Having to build
>-> adapters to translate (if possible) credentials in different formats
>-is
>-> a compromise which is more reasonable than having to wait for all the
>-> middlewares of the world to move towards a common security
>-> infrastructure.
>-
>-In the short term... documenting and defining the 2 or 3 security models
>-is real progress. If a service only supports one of these I do not see
>-this as a problem - for all the reasons given. Providing credential
>-translation services to provide 'shims' (or bridges between these
>-islands) as an interim solution makes this work. Its a low risk to
>-individual services - they maintain their current stability - and can
>-migrate over time to support both or the most 'popular' one - let the
>-market decide!
>-
>-Each service can then advertise the mechanisms it supports and clients
>-can locate credential translation services as required.
>-_______________________________________________
>-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/20090326/0d6eecb9/attachment-0001.bin 