**Authorization Framework**

1.  **Requirements**

> Two key enhancements to the GT4.0 authorization framework are to
> facilitate attribute/role-based authorization and to allow for a more
> flexible support for the fine-grained expression of the delegation of
> rights.
>
> It is clear that attribute/role-based authorization is an important
> trend, and we see the requirements for our toolkit to support
> attribute assertions in all kinds of different formats, like ldap,
> SAML, X509 attribute certificates, resource properties, etc. As a
> consequence, we also see the need to communicate those attributes to
> the PDPs that will use the attribute values in their policy
> expressions to evaluate authorization decisions. In order to support
> truly pluggable PDPs, a standardized, canonicalized format for the
> attributes is required to communicate their values. Our attribute
> collection framework will gather the attributes obtained through the
> different mechanisms, translate them to a canonicalized format, and
> present them through a standardized interface to the different PDPs.
>
> Delegation of rights is a crucial feature for Grid computing. Our
> present webservices security framework relies on the
> X.509-proxy-certificates to empower intermediates to work on behalf of
> the original requester. After a successful X.509
> (proxy-)certificate-chain path validation, the subject of the
> end-entity certificate at the start of the chain is identified as the
> requester of the service invocation, and all subsequent authorization
> decisions are based on that original requester.
>
> In order to allow alternative and more fine-grained mechanisms to
> express delegation of rights, like SAML and XACML authorization
> assertions, restricted proxy-certificates, or external PDPs, we are
> building a more sophisticated authorization processing framework. This
> framework will be able to find valid decision chains from original
> requester to resource owner through the evaluation of the different
> authorization statements expressed in the different policy languages.
> The authorization decision evaluation is obtained through a
> standardized, pluggable PDP interface that abstracts the different
> kinds of policy mechanisms. As a result, any mechanism-specific PDP
> will be able to contribute its evaluation result for the search of a
> valid decision chain that would allow the service request to proceed.
>
> =

2.  **Overview**

> The authorization framework consists of an engine that uses a list of
> Policy Information Points (PIPs) to gather attributes about entities
> and a chain of Policy Decision Points (PDP) to evaluate whether a said
> action can be performed by an entity on the resource. An instance of
> the list of PIPs and chain of PDPs is referred to as an authorization
> chain. Authentication is done outside of this framework and request is
> forwarded to this framework upon successful authentication.
>
> Any subject, resource or action is defined as an "entity." Attributes
> are used to identify and describe these entities. Each attribute has a
> unique name/id, one or more values, issuer identity and some meta data
> about the attribute. The list of PIPs collect attributes about any
> entity. The attributes for a said entity are stored as a collection of
> attributes and made available to the PDP chain. The PDP may consider
> attributes of subject, resource and action in decision making process.
> For example, group membership of a subject, file in an RFT transfer,
> RSL in a GRAM job and so on. The engine evaluates each PDP depending
> on the algorithm configured. For example, in the case of a
> permit-override algorithm, the engine attempts to construct a decision
> chain from the requestor to resource owner and returns permit if such
> a chain can be established. The engine requests two types of decisions
> from each PDP: a) access decision, which determines if a subject can
> access a resource b) administrative decision, which determines if a
> subject can delegate access rights on a resource. Four types of
> decision maybe returned by each PDP and the PDP chain:

-   Permit

-   Deny

-   Not applicable

-   Indeterminate

> The decision returned by each PDP on the chain has an expiration time
> associated with it and the minimum expiration time in the decision
> chain is associated with the authorization chain decision.

3.  **Policy Information Point**

> Each PIP in the authorization chain is used to collect attributes
> about any entity, not only the requestor, action and resource. The
> attribute value collected for one of the entities might depend upon
> the value of other entities. For example an attribute picked up for
> some subject might be that the "role" is "manager", based on the
> action and resource of a particular data set access on a node. But the
> value of the "role" attribute might be different for the same subject
> if the action and resource are different, for example when running a
> job on the node.
>
> Some PIPs might expose a (remote) interface to allow for retrieving a
> particular set of attributes about a said entity. This functionality
> is useful to collect attributes on as-needed basis, while the
> authorization chain is being processed.
>
> Each PIP might return a normalized representation of the collected
> attributes, in addition to the native representation. The former is
> required for the framework to be able to process the attributes to
> group them as a single set of attributes per entity and to be able to
> transfer these to remote PDPs. The PIP might convert only the identity
> attribute(s) to normalized format for the framework to associate the
> set of native attributes with the correct entity. But if the PIP is
> collecting attributes about the request entities, i.e. the requesting
> subject, action and resource, then it need not convert even identity
> attributes since that collection is separately identified by the
> framework and the PIP can just add to it.

4.  **Policy Decision Point**

> Each PDP returns an authorization decision given a requestor, action
> and resource and also has access to all the attributes collected by
> the list of PIPs. A PDP might callback to PIPs that expose an
> interface to get a particular attribute about an entity. This might be
> used for example to attempt to get a required attribute, prior to
> throwing a fault. This feature will require storing meta data about
> attributes, such as the PIP that is used to retrieve a particular
> attribute.
>
> PDPs provide two types of decisions, one regarding access rights and
> another regarding administrative rights. Access rights involve PDP
> assessing if a said subject can perform a said action on a said
> resource. The administrative rights decision declares whether a said
> subject can delegate the right to perform a said action on a said
> resource to some other subject. In simple scenarios, the right to
> access might imply a right to delegate, in which case, both these
> decisions will be identical.

5.  **Authorization Engine**

> The authorization engine orchestrates the evaluation of the list of
> PIPs and chain of PDPs and enforces the decision rendered by the
> authorization chain. The framework can be configured with a bootstrap
> PIP that collects any attributes available about the requestor, action
> and resource. For example, if X509 authentication is used to access a
> WSRF compliant service, than a PIP that collects attributes like the
> X509 subject of the requestor, the operation that was invoked and the
> resource on which the operation was invoked can be configured. Another
> example is that it will place the time of access into an attribute of
> the action. The bootstrap PIP is different from the other PIPs in that
> it is expected to pick up attributes about the requestor, requested
> action and requested resource. The attributes collected by the PIPs
> are grouped as collection of attributes per entity and stored in a
> "context store" that is accessible to the PDPs also.
>
> The PIP also collects a special set of attributes called the
> "environment attributes" that contain information that is not
> associated with any specific entity, but might be useful in the
> decision process. For example, the current time would be one such
> attribute.
>
> The engine can be configured to use various "Policy Combining
> Algorithms" to process the decisions returned by individual PDPs.
> Examples of some such algorithms are:

-   Deny override -- if a "deny" is returned by any PDP in the chain, a
    deny is returned. If no PDP in chain returns deny, a permit is
    returned.

-   Permit override -- if a single permit decision chain is returned, a
    permit is returned. If no permit decision chain is found, deny is
    returned.

-   First applicable -- if a "permit" or "deny" is returned by any PDP,
    the decision is returned and rest of the chain is not evaluated.

> The proposed engine has following processing steps:

1.  **Bootstrap PIP**

> This PIP, if configured, is used by the framework to retrieve
> attributes about the requestor, action, resource and environment. The
> collection of attributes returned for each entity are stored in the
> context and are then used in subsequent calls.

2.  **Administrative first applicable authorization chain**

> In this step the framework evaluates a configured authorization chain,
> with deny override as policy combining algorithm for the PDP chain. A
> permit or deny here, returns the decision and rest of the framework is
> not exercised. A "not applicable" here, leads to evaluating rest of
> the chain. "Indeterminate" is treated as an error and an exception is
> thrown. This phase is used to allow for an administrator
> configuration, like a site wide white or black list.

3.  **PIP list**

> The framework invokes each of the configured PIP to retrieve a
> collection of attributes about any entity the PIP knows. It then
> attempts to collapse the collection by matching identity attributes
> and grouping already collected attributes about an entity with those
> returned by the PIP. In the most naïve approach all the configured
> PIPs will be invoked one after another to collect attributes.
> Moreover, the whole PIP list will be evaluated each time a decision is
> requested.
>
> Enhancements in PIP list processing:

-   Threaded run:

> Each PIP can be run on a separate thread. A synchronized wait thread
> waits for the threads to finish. A time limit can be set, such that
> any PIP that takes longer than the specified ceiling time to finish
> will be terminated. Attribute collapsing will need to be coordinated
> (likely by callbacks to the synchronized wait thread).

-   Persisting collection of attributes:

> The attributes collected can be persisted so that they can be re-used
> in subsequent runs. Based on the requestor's identity attribute as
> key, the attributes stored for a given authorization chain can be
> retrieved. If any one of the attributes has expired, the PIP list
> needs to be processed again. This feature can be sped up some more, by
> caching these attributes in memory. \[\[One thing that needs to be
> added to our thinking about caching: a mechanism needs to be developed
> such that the client can request that the current cache be cleared --
> what if it wants to switch to its other role in the VO?? Currently, in
> VOMS, this is taken care of by the user switching proxies and pushing
> new attributes. But this will not work if the attributes are
> cached.\]\]
>
> If the attributes about an entity are collected in the context of
> values of attributes for other entities, then the key for retrieving
> the data would be collection of attributes for subject, resource and
> action. For example, a subject is a VO admin only if accessing a
> particular resource, but is a VO user for other resources.

-   Persisting meta data about attribute collection:

> Another enhancement would be to persist the PIP instance used to
> collect a particular attribute. In this case, if an attribute has
> expired, then only the PIP that was used to collect it needs to be run
> again.\
> \
> An even further enhancement would be to pick particular PIPs to run
> based on only those attributes that were expired and useful to the
> authorization decision (this is only an "educated guess" of the
> framework, since a PDP might also base its decision on other factors,
> such as time of the access, etc, so it will be able to be turned off).

1.  **PDP chain**

> The PDP evaluation if permit-override combining algorithm is used, is
> described in detail in the document, "", by Frank. Some notes from the
> document are listed below

-   Right to access implies right to delegate

-   Each PDP has an issuer of decision represented by subject DN and the
    framework interprets a decision returned by PDP as the issuer
    permitting or denying the subject access to resource.

-   The resource owner and requestor are identified and treated as
    special subjects.

-   Following checks can be eliminated:\
    No decision by requestor is relevant\
    No decision on self matters\
    No decision on resource owner matters.

-   Any decision by resource owner on requestor is a final decision and
    stops further evaluation.

-   Access chain is transitive (if I permits J, J permits K, then I
    permits K)

-   The evaluation engine uses permit override mechanism.

-   The engine attempts to identify a permit decision chain from the
    resource owner to requestor.

> Enhancements to framework

-   Delegate rights

> An enhancement to PDP processing while constructing the decision chain
> would be to not assume that right to access implies right to delegate.
> Each PDP could be asked different question to determine if a subject
> has access and delegate rights.

-   Persist decision rendered

> Each decision rendered by an authorization chain, given a collection
> of attributes, can be persisted for use in subsequent calls. So prior
> to processing the PDP chain, the store can be looked up and if a valid
> decision exists, it can be used. This can be further enhanced by
> caching some of the decisions, so a look up to some persistent store
> is saved.

Caching the decision to not have to go to the persistence store each
time.

6.  **Scenarios**

    1.  **Scenario 1**

> If we have an x509 EE cert for Rachana that is used for the
> authentication of her request, then after the x509 path validation, we
> end up with two attributes:
>
> attr1 = Attribute ( name=\"x509SubjectDN\", value=\"CN=Rachana\",
> identity=true)
>
> attr2= Attribute( name=publicKey,
> value=\"#\$%\$\^&\$&Rachana&\*\^\*&#\", identity=true)
>
> We \"know\" that both of these attributes are identity attributes for
> the entity, and we know they refer to the name entity, so we can add
> them to the same set:
>
> entity1 = Set(a1, a2)
>
> Furthermore, we \"know\" that this entity was associated with the
> \"requester\" of the service invocation, so we keep this special
> relationship by assigning:
>
> theRequester = entity1
>
> We also \"know\" what the request is in the form of a porttype,
> resource, action, such that we can fill-in
>
> attr3 = Attribute( name=\"portType\" value=\"fileTrabsferPortType\")
>
> attr4 = Attribute( name=\"resourceId\", value=\"#%%@resrcId\$\$%#\",
> identity=true)
>
> entity2 = Set(attr3, attr4)
>
> theResource = entity2
>
> attr5 = Attribute( name=\"operation\" value=\"uri:\...read\")
>
> entity3 = Set(attr5)
>
> theAction = entity3
>
> Now we are ready to ask the question whether the resource is allowed
> to invoke the operation on the ws-resource. We do that through a
> function where we pass a list of all the attribute sets, and where we
> separately pass the references of the subject/resource/action
> entities:
>
> decisionResult = accessPDP( List(entity1, entity2, entity3),
>
> theRequester,
>
> theResource,
>
> theAction)
>
> If this would be a call-out, then you would pass the list of entities
> by value, and the subject/resource/action as references to one of the
> passed sets.

2.  **Scenario 2**

> Building on Scenario 1, suppose that an attribute assertion was pushed
> with the request or that an attribute service was configured to be
> called, and that the asserted attribute was a \"group\" with value
> \"anl\" and asserted through an signature signed by someone with an
> x509 EE cert with subject name \"tim\", then we would have the
> following in addition to the requestor, action and resource attribute
> collected from the X509 EE Certificate used to authenticate the
> request.
>
> First we create a new entity for Tim, because we couldn\'t find any
> existing entity set that matched the following two identity attribute
> values:
>
> attr6 = Attribute(
>
> name=\"x509SubjectDN\",
>
> value=\"CN=Tim\",
>
> identity=true)
>
> attr7= Attribute(
>
> name=publicKey,
>
> value=\"#\$%\$\^&\$&Tim&\*\^\*&#\",
>
> identity=true)
>
> entity4 = Set(attr6, attr7)
>
> Then we can use this new entity in the new attribute as the issuer.
> The subject of the attribute assertion had CN=Rachana, so we can find
> that entity1 has a matching identity attribute with the same
> name/value, and we can subsequently add the new attribute to that set:
>
> attr8 = Attribute(
>
> name = \"group\",
>
> value = \"anl\",
>
> issuer = entity4
>
> entity1 = entity1.add(attr8)
>
> and finally the PDP function call that would have Tim\'s entity added
> to the list, while Rachana\'s additional attribute was added to here
> entity\'s attribute set:
>
> decisionResult = accessPDP( List(entity1, entity2, entity3, entity4),
>
> theRequester,
>
> theResource,
>
> theAction)
>
> So even we don\'t know whether the new attribute will be used, or if
> the new entity will be used inside of the PDP function, we pass all we
> have.

3.  **Scenario 3**

> Building on Scenario 2, assume that Rachana also pushes an
> authorization assertion signed by Frank, plus another attribute
> assertion for Frank, signed by Tim.
>
> Then the authorization assertion\'s signature will be validated, and
> the issuer will be known through its x509 cert, which in this case
> will yield yet another new entity:
>
> attr9 = Attribute(
>
> name=\"x509SubjectDN\",
>
> value=\"CN=Frank\",
>
> identity=true)
>
> attr10= Attribute(
>
> name=publicKey,
>
> value=\"#\$%\$\^&\$&Frank&\*\^\*&#\",
>
> identity=true)
>
> entity5 = Set(attr9, attr10)
>
> The new attribute assertion will have a subject that will match Frank,
> such that it should be added to the associated entity5, plus the
> issuer can be matched to Tim\'s entity4:
>
> attr11 = Attribute(
>
> name = \"group\",
>
> value = \"anl\",
>
> issuer = entity4
>
> entity5 = entity5.add(attr11)
>
> Finally, the PDP call will look like:
>
> decisionResult = accessPDP( List(entity1, entity2, entity3, entity4,
> entity5),
>
> theRequester,
>
> theResource,
>
> theAction)
>
> Note that Frank\'s authorization assertion has also yielded a new PDP
> instance for that authorization statement that may or may not be
> called in subsequent PDP function call inside of the accessPDP call to
> find the delegation chains.
>
> So that function call would look like:
>
> theAdmin = entity5
>
> decisionResult = adminPDP( List(entity1, entity2, entity3, entity4,
> entity5),
>
> theAdmin
>
> theRequester,
>
> theResource,
>
> theAction)