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.

1. 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.

2. 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?

3. 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/

4. “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.

5. 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..

6. 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.

7. 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