Cloud Authorization Use Cases Version 0 Committee Note 01 19 November 2014

Use case 5: Employing a “Reliability Index” in federated policy decision flows

Download 466 Kb.
Size466 Kb.
1   2   3   4   5   6   7   8   9   10   11

1.12Use case 5: Employing a “Reliability Index” in federated policy decision flows

1.12.1Description/User Story

When designing a policy within a federated authorization system, the policy designer places a high degree of overall system integrity in the ‘quality” of the attributes used in a given policy decision. The active exchange of attributes and data between relying parties in distributed cloud / federated authorization systems, makes it hard to design policies that allow for the varying levels of controls & assurance placed around attribute management lifecycle controls.

This user story introduces the use of a “reliability index” to help providers and consumers define, model and understand an integrity rating for a given attribute, set of attributes or attribute provider By employing a reliability index for the attribute provider and for the specific attributes it provides, the policy designer is able to create more meaningful access policies, policies that reflect the dependencies, reliability and overall risks inherent in the authorization system as a whole.

1.12.2Goal or Desired Outcome

The policy author is able to define a policy that allows for the real-time assessment of the reliability of an attribute provider or the individual reliability for any attribute it provides. This allows for varying levels of access control policy to be applied dependent on the value of the reliability index retrieved for the provider and/or its attributes. When reliability is low, the policy author defines more approval/controls and less access for the same decision matrix, applied to the same set of identity attributes. This should allow for better decisions to be made.

1.12.3Applicable Deployment and Service Models

This user story applies to the following cloud deployment and service models Deployment Models:

Private, Public, Community, Hybrid Service Models, Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS)

1.12.4Actors Attribute Authority

The logical entity that provides an attribute for use in the evaluation of a policy. Policy Author

The author or creator of a given access authorization decision policy. Policy Decision Point

The logical entity that makes policy decisions for itself or for other network elements that request such decision. Specific Subject

A user of the system.



1.12.6Notable Services Provider Reliability Index Service

A service that provides a reliability index value called Provider Reliability Index for an Attribute Provider. The service also provides a reliability index value called Attribute Reliability Index for each attribute to the Attribute Providers. Attribute Provider Service

A service that has an Attribute Authority as well as provides a reliability index value called Attribute Reliability Index for each attribute.


An operating trust model exits within a federated access authorization system. The overall system is appropriately configured to allow for policy decision flows in accordance with the use case.

1.12.8Process Flow

The Policy Author writes a policy that only provides access to Protected Resource if the Specific Subject is over 21.

The Attribute Provider asserts that a Specific Subject has Over 21 attribute and carries out a physical driving license inspection and an in person interview. The Attribute Provider places a very high Attribute Reliability Index to its Over 21 attribute due to its strong internal control procedures.

In this case, the Attribute Provider is awarded a high Provider Reliability Index because it is the Texas DMV and is the actual issuer of the driving license in question.

When the Specific Subject is over 21 and either of the Attribute Reliability Index or the Provider Reliability Index is high, the Specific Subject provides direct access to Protected Resource. If either the Attribute Reliability Index or the Provider Reliability Index is not high, then Specific Subject is asked to confirm their age before being provided access to Protected Resource.

1.13Use case 6: Distributed Authorization

1.13.1Description/User Story

Enterprises and corporations are usually composed of different working areas or departments: human resources, operations, business office, administrative office, etc. Each corporate area may implement its own access control rules that handle the information and resources in their respective areas and are, somehow, enforcement points.

However, some authorization decisions may depend on the information belonging to other areas or domain, which cannot be directly accessed due to privacy issues. In this sense, instead of recovering the required information, the authorization decision is delegated to the areas that could handle it, and the results of such delegated decisions are combined to form an appropriate decision.

1.13.2Goal or Desired Outcome

Authorization decisions are taken based on the decisions of multiples cloud computing parties.

1.13.3Categories Covered

  • Authorization.

  • Account and Attribute management.

1.13.4Applicable Deployment and Service Models

  • All Cloud Deployment Models (Private, Public, Community and Hybrid).

  • All Service Models (SaaS, PaaS and IaaS).


  • Cloud user.

  • Cloud Resource.

  • Local Policy Decision Point

  • External Policy Decision Point

  • External Attribute Authority



1.13.7Notable Services

  • Cloud Authorization Service

  • Cloud Entitlement Service




Access control policies are deployed among different administrative domains or areas. Each area deploys policies related to the information they manage.

1.13.10Process Flow

A Cloud User belonging to the administrative domain A tries to access a Cloud Resource controlled by the administrative domain B. To determine if the Cloud User has access to the Cloud Resource, the authorization policies of both domain A (e.g. only users with a specific role could access to external resources) and B (e.g. only users belonging to a specific domain could access to the given Cloud Resource) have to be evaluated. The Policy Decision Point of the domain B evaluates its policies and it requests the Policy Decision Point of the domain A for its authorization decision. The decision from the domain A is combined with its own policies to form the final authorization decision.

Share with your friends:
1   2   3   4   5   6   7   8   9   10   11

The database is protected by copyright © 2019
send message

    Main page