[Pgi-wg] Sec: Agreement on attribute transport mechanisms for AttrAuthZ

[m.riedel at fz-juelich.de]

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


(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.

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


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

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

# 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 at 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
-------------------------------------------------------------------
-------------------------------------------------------------------