Is XACML the only fine grained authz standard ?

1. Is XACML the only fine grained authz standard? For policy expression, it 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. Site Minder has more adoption in the market, although it’s 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 (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 Site Minder 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.

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

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

4. 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 Site Minder 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.

5. 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 sso 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). Enterprise 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: 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.

6. 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. 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. Article resource:-http://gluu.soup.io/post/435069266/Is-XACML-the-only-fine-grained-authz