>-On Friday 20 March 2009 09:22,
m.riedel@fz-juelich.de wrote:
>-> Hi PGI Security team,
>->
>-> after discussing possible AA interface that gives us insights into the
different
>-"attribute package" formats, we can discuss the transport of them (or as
said by
>-Steven: The presentation of these packages at the (functional services).
>->
>-> ### Goal:
>->
>-> (a)
>-> We are discussing the transport of agreed attribute packages that are
used in PGI
>-to achieve attribute-based authorization (overcoming pure id-based
authZ)...
>->
>->
>-> (b)
>-> ...because we want to specify exactly where services can expect the
"attribute
>-packages" in the request messages...
>->
>->
>-> (c)
>-> ... in order to find out if we can agree on simple "attribute-package"
transport
>-paradigms that are easy to understand and don't allow for too much
flexibility to
>-promote interoperability.
>->
>->
>-> ### (Agreed) Attribute Packages so far
>->
>-> (a)
>-> SAML assertions with attributes of end-users
>->
>-> (b)
>-> VOMS ACs with attributes of end-users
>->
>->
>-> ### StrawmanFoundational: 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).
>-> Supplemental: Conveying authorization attributes describing aspects of
virtual
>-organization membership.
>-> •X.509 proxy + attribute certificates (PGI_TLS_PROXY). X.509 proxy
certificates
>-exchanged at the SSL/TLS level, demonstrating ownership of any X.509
attribute
>-certificates embedded within. This conformance target derives
foundational
>-requirements from PGI_HTTPS.
>-> •SAML attribute assertions (PGI_SOAP_SAML). Demonstrating ownership of
>-SAML attributes exchanged within the SOAP message header. This
conformance
>-target derives foundational requirements from PGI_HTTPS.
>->
>->
>->
>-> ### proposal of easy plumbings: Attr-based Authorization profile
>->
>-> The plumbings idea refers to the fact that the PGI security should be
EASY to
>-understand and less flexible compared to the wide variety of (OGF,OASIS)
>-specifications having the least dependencies to other specs as possible.
>->
>-> // precondition
>-> (a) Authentication profile as one plumbing to be agreed before
(precondition)
>-> Simple: You agree on either on full X.509 certs (TLS) or restricted
X.509 proxies
>-(GSI) on transport level
>-
>-I see no reason for "either". Also it would be nice to define used terms.
>-AFAIK there are no restrictions for using X.509 proxies (aka PC) in TLS.
As long as
>-we are talking about
>-standardaized PCs (RFC 3820) of course.
>-For infrastructures relying on full or partial/restricted X.509 identity
delegation PC
>-(proxy certificate) is
>-a must. But I see no reason why that should exclude usage of ordinary
X.509
>-certificates/keys as
>-mean for identifying (direct or through attributes) communicating parties.
>-
>->
>->
>-> (b) Attr-based AuthZ profile as another plumbing to be agreed on top of
AuthN
>-> Simple: You agree on either SAML assertions or AC VOMS attribute
packages.
>-
>-Here I see no reason on either again. As long as information carried
inside
>-assertion/attribute is
>-semantically identical (or at least convertable) the envelope used to
carry it is of little
>-importance.
>-Of course both ways should be properly defined - without "this is out
scope and
>-should be provided
>-by other profile" sentences.
>-As for comparing SAML assertions to VOMS AC safety wise both provide
adequate
>-measures for ensuring
>-integrity and ownership of enclosed information.
>-
>->
>-> (c) transportation profiling (with two ways so far)
>->
>-> 1: if you agree on SAML assertions we put it in the SOAP header in
WS-Security
>-> (works for both options in AuthN)
>->
>-> 2: if you agree on VOMS AC we put it in the extensions of X.509
certificates
>-> (works for both options in AuthN)
>-
>->From point of view of ARC codewise there is no technical problem to
>-support both of them and also other 2 combinations of them as long
>-as all are properly defined.
>-Pesonally I would choose both for ARC services just to increase
interoperability.
>-
>->
>->
>-> Bottom Line plumbings -> Simple: One Agreement on AuthN and one
agreement
>-on AuthZ (two plumbings rather independent from each other like within
>-pipes/plumbings in a house such as warm water, sewage, cold water, etc.)
>->
>->
>-> Example: It doesn't matter if you put warm water (full X.509 certs for
AuthN) or
>-cold water (proxy X.509 certs for AuthN) into the plumbings/pipes -
important is to
>-know what is in the plumbing and thus the middleware is able to handle it
(possibly
>-via different handlers in modern container designs).
>-
>-If You extend idea of pipes to cars there are modern cars which are able
to run on up
>-to 3 kinds of fuels. Why should Grids be worse?
>-
>->
>-> ### Possible conclusions
>->
>-> # We need an easy mechanism to perform attribute-based AuthZ
>->
>-> # Mechanisms for AuthZ decisions are out of scope as well as having a
specified
>-policy (ACLs, XACML) - they are considered to be implementation detail
>-
>-Do Yu mean "out of scope of this mail thread" or "out of scope of PGI"?
>-
>->
>-> # We have to agree on the structure / Semantics on attributes (seperate
e-mail
>-thread soon)
>->
>->
>->
>-> ### open Questions:
>->
>-> Q: Is the plumbings idea just oversimplified? It's not exactly
specified, which can
>-be done after agreeing to its element easily. What is the problem with the
above
>-mentioned plumbings.
>->
>-> Q: What are the problems of the PGI communication strawman
differentiation
>-mentioned above?
>->
>-> So let's discuss this important thread before the telcon, but please
keep the
>-structure and semantics of attributes (FQAN, etc.) out of this discussion
for now
>-(seperate e-mail thread)
>->
>->
>-> Take care,
>-> 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@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.'
>->
>->
>->
>-> -------------------------------------------------------------------
>-> -------------------------------------------------------------------
>-> 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
>-> -------------------------------------------------------------------
>-> -------------------------------------------------------------------
>->
>->
>-> _______________________________________________
>-> Pgi-wg mailing list
>->
Pgi-wg@ogf.org
>->
http://www.ogf.org/mailman/listinfo/pgi-wg
>->
>-_______________________________________________
>-Pgi-wg mailing list
>-
Pgi-wg@ogf.org
>-
http://www.ogf.org/mailman/listinfo/pgi-wg