Policy support at the Authorization Manager
The SMART project has implemented a fully functional prototype software for the UMA protocol. We have developed the Authorization Manager (smartam), two exemplar Hosts (smartgallery and smartfs) and a Requester Web application (smartfetch). We’ve developed all the applications in Java with the use of such frameworks as Spring, Spring MVC, Apache CXF, Hibernate, and others. Our prototype AM and Hosts can be used by the Authorizing User and the Requester can be used by Requesting Parties. If you feel like you’re not familiar with this terminology or you’re not sure about the purpose of each component of the UMA eco-system then definitely check out the UMA 1.0 Core Protocol specification.
We’ve been recently asked about the policy types that we support in our Authorization Manager, so I’ve decided to write up about that. The Authorizing User, let’s call him Bob, can use our prototype smartam to define a set of policies for the resources that he wants to protect. Bob, defines these policies using a designated UI at smartam. It is when Bob can define multiple different policies to cover possibly different sharing scenarios. E.g. a Bob can define a policy that defines which of Bob’s friends can have a “read”-type access to protected resources.
Then, Bob needs to define which resources will be protected by smartam. By defining “protected resources” Bob tells his Hosts (e.g. smartgallery and smartfs) that they should refer to smartam if they receive an access request to these resources. Bob can also group resources and these groups can comprise of individual resources from the same or different Hosts. For example, Bob could create a group of “Holiday Resources” from short video clips stored at smartfs and photos stored at smartgallery. Obviously, groups can contain other groups, etc.
When Bob has successfully defined policies and has specified protected resources, then Bob is able to combine these two together. What it means is that Bob creates Baskets – i.e. attaches a resource or a group of resources with a policy or multiple policies. It is then up to our policy engine developed for smartam to evaluate these policies according to some rules. Currently, we do not expose any configuration options regarding how policies should be evaluated and how conflicts should be resolved but this will probably change once we know better what users expect to see.
So once we know how Bob can create policies and how these policies can be linked to resources, let’s take a closer look at the policies themselves that are supported by smartam. The policy currently comprises of two sets: Rules and Claims. A single rule defines a set of Requesting Parties and a set of access rights that these Requesting Parties possess. A single claim defines properties that the Requesting Party must prove to possess to the Authorization Manager. Following is a short description of how these are evaluated by our policy engine:
- If a policy only has Rules then Requesting Parties must authenticate to the AM to prove their identity. Then the engine checks if the requested access type matches the one specified in the applicable rule.
- If a policy only has Claims then any Requesting Party that proves to possess some properties can have access to a resource. Access type is restricted to defined types in the policy.
- If a policy has both Rules and Claims then Requesting Parties must both authenticate and submit claims for evaluation by our policy engine. Only then access to a resource can be granted.
Below are some screenshots from smartam that show how Bob could define a single policy that contains both Rules and Claims (1a,1b,1c), add a protected resource on smartgallery (2), and link this newly defined policy with this protected resource (3).