Role of VOMS in the authorization framework

Background

Developing a SAML enabled VOMS we need to be compliant with [OGSIAuthzService], the GGF standard for authorization services using SAML. The problem with [OGSIAuthzService] is that VOMS doesn't have the semantic of an authorization service as it is defined in [OGSIAuthzReq] to which [OGSIAuthzService] refers

services ... are given a description of the initiator ... , a description of an action being requested ..., details about the target resource to be accessed, .. and they provide an authorization decision whether the action should be processed or rejected.

or in [OGSASecurity]

is concerned with resolving a policy based access control decision ... consumes as input a credential a credential ... and for the resource that the service requestor requests, resolves based on policy whether or not the service requestor is authorized to access the resource

In the latter document an attribute service is mentioned but no description is given. In the first, authorization services are said to be possibly supporting attribute assertion from external sources both in push and pull model. The better description of both models is in the RFC 3281.

Attribute Service is probably the best 'name' for VOMS, which semantic is - given a description of the initiator, a set of attributes, and other contextual informations such as the requested validity for the assertion, it provides an assertion regarding attributes possesed by the initiator.

OGSA Authorization Service interface

Despite differences in the semantic, the WSDL interface of the OGSA SAML Authorization Service defined in [OGSIAuthzService] can serve the purpose of a VOMS SAML service. It indeed defines a single operation

<message name="SAMLRequestInputMessage">
  <part name="body" element="samlp:Request">
</message>

<message name="SAMLRequestOutputMessage">
  <part name="body" element="samlp:Response">
</message>

<operation name="SAMLRequest">
  <input message="tns:SAMLRequestInputMessage">
  <output message="tns:SAMLRequestOutputMessage">
</operation>

which wrap the SAML Request-Response protocol, thus allowing handling both authz decision, which are requested by mean of a AuthorizationDecisionQuery inside a Request element and included in assertions with the AuthorizationDecisionStatement element, and attribute assertion, which are requested via an AttributeQuery element inside a Request element and included in assertions with the AttributeStatement element.

Being the input of the SAMLRequest operation a samlp:Request, the WSDL can serve for both authorization and attribute services (and authentication services via AuthenticationQuery and AuthenticationDecision). Here we've been referring to SAML v1.1. However, things get a little more complicated when coming to V2.0: AttributeQuery and AuthorizationDecisionQuery (now AuthzDecisionQuery) are sent for processing as upper most element instead of being embedded in a Request type. Thus the difference beetween Authorization Service and Attribute services is more evident when using SAML V2.0 and a change of the WSDL will be needed. It would still be possible to define the input of the SAMLRequest operation as a

<message name="SAMLRequestInputMessage">
  <part name="body" element="samlp:RequestAbstactType">
</message>

using the abstract type RequestAbstractType (is it legal to use an abstract type there?) from which AttributeQuery and AuthorizationDecisionQuery are derived but it sound more sensible to define different interfaces that uses the different types. Actually, SAML V2.0 construct reflects exactly the semantic differences beetween an Authorization Service and an Attribute Service

• an Authorization Service consume a SAML Request containing an AuthorizationDecisionQuery and release a SAML Response containing a AuthorizationDecisionStatement.
• an Attribute Service consume a SAML Request containing an AttributeQuery and release a SAML Response containing a AttributeStatement

Goals

• Producing a document that define the role of an Attribute Service in a grid authorization framework.
• Define a better interface for an Attribute Service.

References

[OGSAAUthzReq] Welch V. et al., OGSA Authorization Requirements, June 2003, available at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-authz/docman.root.requirements/doc9053

[OGSAAuthzService] Welch, Siebenlist, Chadwick, Meder, Pearlman, Use of SAML for OGSA Authorization, September 2003, available at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-authz/docman.root.authz_service/doc9006

[OGSASecurityRoadmap], Siebenlist et al., OGSA security Roadmap, OGSA Security WG, GGF, July 2002, available at http://www.cs.virginia.edu/~humphrey/ogsa-sec-wg/

[OGSASecurityArch], The Security Architecture for Open Grid Services, July 2002, available at http://www.cs.virginia.edu/~humphrey/ogsa-sec-wg/