Issuu on Google+

Is XACML the only fine grained authz standard No, in conjunction with OpenID Connect (which provides an OAuth2 profile for authentication), the UMA profile of OAuth2 can also be used to centralize authorization within a domain or federation.

What is XACML?

The OASIS XACML version 3 standard defines a common XML syntax for expressing security policy. If you manage IT security for a very large organization, you may have several access management systems, for example SiteMinder and Oracle Access Manager. Wouldn’t it be great if the policies you write in one, were portable to another? Also, a standard syntax for policies makes it easier to “normalize” policies across the organization, both to consolidate and govern.

However, adoption of XACML by Internet domains has been tepid at best. There are approximately 250 million Internet domains out there–only the most microscopic subset of those have a XACML PDP. It has gained some big supporters–security paranoid organizations like the military love it! But for the most part, XACML is a standard only of interest to serious security nerds.

Here is a somewhat simplified XACML policy adapted from the spec. I’m not a XACML expert, but I think it says the person must be from the “” domain:

What is UMA?

Abstract: User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy.

Centralized Authorization is more important than policy normalization

In my opinion, for 99% of the domains out there, the most important security benefit is derived from centralized authorization, not from standard policy expression. Consolidation saves money and improves security. Where business logic is shared between applications, code duplication is a waste of effort and makes maintenance more difficult. For example, if a school district hosts multiple websites, it would be inefficient to support each website writing code to call your database to check

if the person is a teacher. It would be much better if the website could make a call to a central service, to make sure the person has “teacher” authorization. In this way, the district can implement the business rules to determine who is a teacher in one place. Note: the app doesn’t care how the policy itself is expressed. It just wants to make sure that the district has decided the person is a teacher…

UMA supports PDP and PAP diversity

It was a wise choice by the UMA editors to stay neutral on policy expression and management. It enables vendors to implement a number of different approaches to policy management, including XACML–if that’s your organizational preference.

There are a number of solutions for entitlements management. XACML is just one. Some organizations use Repose or Permis, or even commercial IAM product for entitlements management.

One of the functions of the “Policy Administration Point” or “PAP”, is to provide tools for the domain administrator to manage policies. IAM tools differentiate themselves on the usability of the PAP. For example, CA SiteMinder has a graphical interface that enables domain system admins to define Rules which specify URLs, and policies, which say “who” can get to those URLs. oxTrust has a web UI and REST interfaces to enable policy management. IBM Tivoli Access Manager even has a command line interface (in addition to the Web UI and API) for policy management.

UMA doesn’t say who makes the policy decision

To paraphrase, UMA just says “a decision is made.” As mentioned above, it doesn’t say how the logic behind the policy is implemented, or even who makes the decision. UMA was designed to enable a person to centrally manage authorizations granted to domains. Recently, Gluu helped clarify a use case for Enterprise UMA. In this case, the organization, not the person makes the decision whether to allow access to a resource, specifically for web access management. The sequence diagram below documents the flow for the OX implementation of Enterprise UMA. If you are familiar with XACML, the “Host” would be the PEP; oxAuth would be the PDP; “oxAuth Admin” is where the PAP where admins can authorize manually or define policies.

UMA can’t do it alone… authz needs authn!

Most commercial identity and access management (IAM) suites provide two key services: authentication (identity) and authorization - web access management. It would have been silly for UMA to define a endpoints for authentication… this was work was in progress at the OpenID Foundation. OpenID Connect provides several workflows for authentication, discovery, client registration, and user claims (attributes).

Enterpise UMA Example : Design for an Apache PEP

So how does UMA work? Consider the example below, which is the result of work being crowdfunded to build open source OAuth2 plugins for the Apache HTTPD server:

Without going into too much detail, the idea is that a web server can specify that certain UMA scopes are required for access to a folder. The web server is not limited to one authorization server… it can query a number of different policy servers whose authorization is required. For example, at an army hospital, access may require the evaluation of Department of Defense, Army, and Hospital policies. Centralization is good, but there can be multiple authorities that centralize policies.

There can be a one:many relationship between scopes and policies. The UMA PDPs determine which policies need to be evaluated for each requested scope.

Enterprise UMA Example: Policy Expression in OX

So how could the PDP use the UMA Scopes? The following screenshot of OX should give you an idea. Vendors will differentiate themselves on how easy they make it to express policies. OX has a geeky approach: we let the domain provide Python syntax code to define the business logic for the “authorize” method. This lets companies express policies based on user claims, call web services, centralize logging, or even make a request for entitlement to an external system, maybe even a XACML PDP. From the website perspective, this is invisible. The PEP just requests that the policies be evaluated for the respective scope. oxTrust_policy_screenshot

Article Recourse:

Is xacml the only fine grained authz standard