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