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 persons 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 scopes 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 lets consider this use case. Lets 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: Lets say you are building delegated administration into your application, and you want to program who can change someones password? Perhaps you are authorized only to change someones 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/

OpenID Connect Scopes enable the federation to group the user claims. If a federation has defined custom user claims, they may also need to define OpenID Connect scopes to include these additional claims. Client Claim Schema Sometimes policy can be driven by attributes of the website. For example, if certain websites are classified as research, the IDP may have a different default attribute release policy. UMA Scopes UMA scopes are typically URLs that identify federation standards for policy evaluation. For example, the federation could define a scope http://myFederation.org/uma/scopes/finance (Finance Scope) In this way Relying Parties could submit a standard query to any authorization server to find out if that person has that permission. The policies behind this permission may vary from Participant to Participant. Participant A might specify that someone is authorized for the Finance Scope if they are in a certain Active Directory Group. Participant B may set the policy for Finance Scope based on network address and time of day. The benefit of the federation standard scope is that applications can make the same request to different authorization servers, requiring less one-off security solutions.

SAML Proxy
A SAML proxy can make it easier for a federation to roll out new websites to its IDP participants. In meshed federations, the IDP must explicitly trust the SP and release attributes. If you have thousands of IDPs in your network, it becomes hard to rollout new websites as each IDP would have to update their configuration to add SSO. Sometimes this is desirable especially if there is little trust in the federation to manage content. However, if the federation is trusted, using a proxy to connect to certain websites can enable people to access new content without their home identity provider having to do any incremental work. Rules Charter This document provides the governance for the federation including the policies, rules, and financial arrangements. Participation Agreement This document is signed by the identity providers and relying parties. In some cases, an organization may be both..

It also details the policies and procedures. Furthermore the Participation agreement defines the level of assurance of the authentication provided by identity providers, and the level of protection for personal data afforded by the relying parties. It can also be a good place to provide guidelines for security incident handling, threat data sharing, and other inter-domain security processes. User Banner Consent Somewhere the person using the federated credentials has to agree to the rules. The best place to do this is at authentication time, so the person knows what he is getting into when he uses the federated credentials to access websites and mobile applications. Steering Committee

Like any collaborative organization, you need to find the people who can help drive adoption in their respective communities. The steering committee should help with the formation of the Charter, provide feedback on the agreements, lead the integrations of the federation in their home organizations, and have a desire to evangelize the benefits of cooperation to industry peers.

Communication Plan
This is marketing for the federation. The federation may want to produce white papers, webinars, case studies, posters, conferences, regional training sessions, newsletters and other activities to get the word out about the federation. The communication plan should be a long term plan to both keep participants up-to-date, and to recruit new participants from the ecosystem. It sounds like a long to-do list, but like any journey, the hardest part is the first step. If you want some help along the way, you may want to schedule a meeting with Gluu. We are helping to catalyze several federations around the globe. Article Resource:-http://thegluuserver.blogspot.in/2014/01/go-west-youngfederation.html