Gluu Blog

Follow us:
Back to Blog

Is XACML the only fine grained authz standard ?

Mike S. October 18, 2013

XACML Overview

Quick Answer

For policy expression, XACML is probably not the only standard for fine grained authz, but it is one of the best known. As an overall architecture for entitlements management… then No. SiteMinder has more adoption in the market, although its not an open standard. OX implements two open standard profiles of OAuth2 which can be used to centralize authentication and entitlements management. OpenID Connect defines how a client (a website or mobile app…) re-directs a person for authentication at their home domain. Connect also defines how a client registers and can get “claims” about a person (like email address). The UMA profile of OAuth2 defines several new tokens which represent fine grain authorizations, and can address situations where two parent organizations may have different sets of policies.

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 “med.example.com” domain:

Sample XACML policy

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 Sequence Diagram

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 (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:

APACHE_CONFIG

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 Gluu

So how could the PDP use the UMA Scopes? The following screenshot of Gluu 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

Summary

Enterprise UMA provides a convenient and flexible design for centralized authorization. In practice, XACML and UMA may be complimentary. However, UMA provides the best way forward.

More Information

[:ja]

 

Quick Answer

For policy expression, XACML is probably not the only standard for fine grained authz, but it is one of the best known. As an overall architecture for entitlements management… then No. SiteMinder has more adoption in the market, although its not an open standard. OX implements two open standard profiles of OAuth2 which can be used to centralize authentication and entitlements management. OpenID Connect defines how a client (a website or mobile app…) re-directs a person for authentication at their home domain. Connect also defines how a client registers and can get “claims” about a person (like email address). The UMA profile of OAuth2 defines several new tokens which represent fine grain authorizations, and can address situations where two parent organizations may have different sets of policies.

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 “med.example.com” domain:

Sample XACML policy

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 Sequence Diagram

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 (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:

APACHE_CONFIG

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

Summary

Enterprise UMA provides a convenient and flexible design for centralized authorization. In practice, XACML and UMA may be complimentary. However, UMA provides the best way forward.

More Information

nbsp;

[:es]

 

Quick Answer

For policy expression, XACML is probably not the only standard for fine grained authz, but it is one of the best known. As an overall architecture for entitlements management… then No. SiteMinder has more adoption in the market, although its not an open standard. OX implements two open standard profiles of OAuth2 which can be used to centralize authentication and entitlements management. OpenID Connect defines how a client (a website or mobile app…) re-directs a person for authentication at their home domain. Connect also defines how a client registers and can get “claims” about a person (like email address). The UMA profile of OAuth2 defines several new tokens which represent fine grain authorizations, and can address situations where two parent organizations may have different sets of policies.

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 “med.example.com” domain:

Sample XACML policy

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 Sequence Diagram

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 (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:

APACHE_CONFIG

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

Summary

Enterprise UMA provides a convenient and flexible design for centralized authorization. In practice, XACML and UMA may be complimentary. However, UMA provides the best way forward.

More Information

nbsp;

Be sure to subscibe to
our RSS Feed

Mike Schwartz

Mike has been an entrepreneur and identity specialist for more than two decades. He is the technical and business visionary behind Gluu. Mike is an application security expert and has been a featured speaker at RSA Conference, Gartner Catalyst, Cloud Identity Summity (now "Identiverse") and many other security conferences around the world.