Role with Attributes but Permission with UMA Scopes Advocates for ABAC (attribute based access control) have a new pun up their sleeve, “Role with Attributes”… haha… as in express the person’s role using an attribute. This pun continues an age old debate regarding whether groups, roles, or attributes should be the focus for managing which people have access to what online stuff.
Whatever you call it, this approach to access management is inadequate. While group membership, user attributes (or user claims in OpenID Connect jargon) and roles can all be important data points for making an access management decision, they co-exist with a myriad of other contextual points that may be considered by an organization in order to make an access management decision. The best way to abstract the business logic is with a “permission”. Luckily, the UMA protocol gives us the perfect place holder to reference this permission: UMA Scopes.
While an UMA scope could be any unique string, it is a good idea to use a URI, which allows the domain to give some context about the scope’s origin. For example, we can call a permission “addPerson”, but if I call it “http://example.com/uma_scopes/scim/addPerson” it would be more obvious to the developer exactly what permission this is. Using a URI to convey a more meaningful domain specific string is also used for the SAML and OpenID Connect acr parameter, and for federation metadata entity ids.
To add fuel to the fire about the inadequacy of “ABAC” and “RBAC”… let’s consider this use case. Let’s say you have a web folder, http://example.com/secure/data. You have one policy requirement from your parent company to use two factor authentication for this resource, and you have two local policies: one that specifies that the site is only available during US market hours, and another that requires that the subject has passed the Series 7 exam this year. The Apache Server configuration might look like this:
The business logic behind these various permissions can be evaluated by the respective UMA Authorization Server (AS) in real time. The AS may evaluate a XACML policy, python code, or may even prompt the subject or another authorized API in real time. It may even query an RBAC system as part of the decision process. But you get the idea… you frequently need more than the role to make a decision, and why architect the security infrastructure to align with a single vector?
Here is another simple example: Let’s say you are building delegated administration into your application, and you want to program who can change someone’s password? Perhaps you are authorized only to change someone’s password if you are their manager. Even for this simple policy the role of the subject only provides half the necessary authorization data.
Consolidating authorization logic in your organization can save you a lot of money, and improve your security. So if you are going to make the leap, use the best tools currently available: UMA Scopes!
Article Resource:-http://thegluuserver.wordpress.com/2014/01/10/role-with-attributes-butpermission-with-uma-scopes/