Role with Attributes but Permission with UMA Scopes

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

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 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?
3
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-but-permission-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-young-federation.html