Welcome!

Security Authors: Yeshim Deniz, Peter Silva, Liz McMillan, Pat Romanski, Hollis Tibbetts

Related Topics: Java, SOA & WOA, .NET, Security

Java: Article

Externalizing Fine-Grained Authorization from Applications

An Entitlements Server allows enterprises to externalize fine-grained authorization from an application’s logic

The recent spike in insider threats, coupled with a rise in compliance considerations, has forced organizations to ensure only authorized users access sensitive application functionality and data. Historically, user entitlements or authorization logic has been embedded inside an application. For example, if the user of an application meets specific conditions, such as a specific role, access to that application function will be granted at runtime. But if the definition of specific authorization conditions changes over time, then the application developer needs to modify the application's source code, test, and re-deploy the application.

Suppose a homegrown portal application must present a sensitive piece of customer information such as a Social Security Number (SSN) when a service representative views a customer's profile. It is determined that in order to ensure compliance with various privacy regulations, only directors and senior managers may be able to view a customer's SSN. A decision has to be dynamically made whenever the application must show an SSN as to whether the current user may view the actual data or some default value (e.g., "XXX-XX-XXXX"). The decision must take into account the user's job title. A dozen parts of the application that can display a customer's SSN mean a dozen places for this business logic to be applied.

Now assume that the policy needs to be changed after the application has been in production for some time. The business has determined that senior managers in California may not view an SSN. This is an exceptional situation that requires another piece of information to be considered as part of the entitlement decision. But what if we take the example even further? Suppose that only directors above a certain salary grade can view SSNs. Now the entitlement logic has been split into multiple decisions based on runtime attributes. So the business logic must be adapted.

You can see that authorization or entitlement policies evolve very differently from application requirements. Having the entitlement logic "hard wired" into the business logic means changing code each time there is a policy change. A lot of organizations also outsource their application development, which means often times they don't own the code that handles the business logic directly. This can lead to further inefficiencies and delays in deploying changes in policies. If we keep the entitlement policies outside of the application, they can be changed without modifying the application.

In this article, we explore a new approach designed to externalize user entitlements from applications through the use of a dedicated access control solution for the application tier. Externalized entitlements mean separating fine-grained authorization logic from business logic. One benefit of this is transparency; the entitlements are now understandable and measurable beyond the context of the application. This is important so that a company may review their entitlement policies for completeness and accuracy against corporate standards.

Roles and Entitlements
Authentication is about validating a user's identity through the use of credentials such as a password, a security card, or a digital certificate. Authorization (or "access control") is the ability to provide an authenticated user access to specific operations of an application.

Authorization is based on the concept of a "role." A role defines what a user is entitled to do. For example, a user in a "broker" role is entitled to transact goods on behalf of others. A role can have qualifying attributes (e.g., seniority, ranking) and can support constraints (e.g., a broker may only start transactions under specific circumstances). Based on his/her role, a user is granted access to specific resources necessary to fill that role.

There are two main kinds of roles: Applications Roles and External Roles. An Applications Role is a collection of users, groups, and other Application Roles; it can be assigned to an enterprise user, group, or External Role in an identity store, or another Application Role in the policy store (see Figure 1). An External Role is the same as an Enterprise Role or Enterprise Group; it's typically implemented as an LDAP group in the identity store.

Application Roles can be many-to-many mapped to External Roles. For example, the external group "employee" (stored in an LDAP-based identity store) can be mapped to the Application Role "customer_support_member" defined in one application and to the Application Role "IT_member" defined in another application.

An Entitlement groups related resources, possibly of different types, needed to perform a business function. In effect, an Entitlement is a reusable collection of access rights that can be granted to multiple principals (users or applications such as web services).

Role-Based and Attribute-Based Access Control
Role-Based Access Control or RBAC, originally defined by NIST [1], formalizes a reference model for controlling access to resources where permissions are not directly associated to users but are defined in roles. The RBAC standard specifies a core set (administrative and system functions) and additional functionality including role hierarchies, constraints, and separation of duty (i.e., "defining a role" and "assigning a role" are separated).

Enterprise RBAC extends RBAC principles to enterprise roles. In addition, Attribute-Based Access Control (ABAC), a natural evolution of RBAC, uses attributes (e.g., social security number or IP address) to define access control rules and access requests (XACML [2] is an example of an ABAC framework). An ABAC policy specifies one or more claims that need to be satisfied before a user is granted access, for example, the user must be a certain age.

Fine-Grained Authorization Model
In a typical XACML-based authorization model, the administrator first defines policies at the Policy Administration Point (PAP), essentially a console allowing policy definition, selection, and attachment. Then attempted access to a protected resource (for example a web service request) is intercepted by a Policy Enforcement Point (PEP), which parses the request and leverages a Policy Decision Point (PDP) to determine whether the request should be granted or denied. The PEP / PDP combination relies on a Policy Information Point (PIP), generally a user directory, to fetch information relevant to the requester for the policy evaluation and policy decision process.

All the access control information required to make the application secure is separate from the application logic and is persisted as modifiable metadata (mostly XML files) packaged with the application.

Fine-Grained Authorization Solutions
A centralized access control solution offers the reuse of authentication and authorization services as well as easier reporting for compliance and regulatory requirements, allowing administrators to control multiple applications through a higher level of granularity.

Java Enterprise Edition (Java EE) application servers provide container security including authorization based on roles. Developers can isolate security code from their business logic and delegate security to the application server infrastructure. However, application server authorization doesn't scale well to the fine-grained access control needs of multiple enterprise applications. A dedicated fine-grained authorization engine is required to complement the functionality provided by the application server.

Introducing Entitlements Server Technology
As previously noted, entitlements are a corollary of roles: being in a specific role entitles you to specific resources. Entitlements are tied to the application as they drive runtime permissions.

Entitlements management enables organizations to define granular access controls for their users based on the attributes of the user, the resource, and the context of the request.

An Entitlements Server is a standalone fine-grained authorization application that allows an organization to protect its resources by defining and managing policies that control access to, and usage of, these resources. Access privileges are defined in a policy by specifying who can do what to which resource, when it can be done, and how. The policy can enforce controls on all types of resources including software components (e.g., URLs, servlets, JavaServer Pages [JSPs], or EJBs used to construct an application), and business objects (e.g., representations of user accounts, personal profiles and contracts such as bank accounts in a banking application, patient records in a health care application, or anything used to define a business relationship).

An Entitlements Server supports the creation of role policies and access control policies. Role policies are used to define constraints regarding which users are assigned roles. Access control policies define access to the software components and business objects mentioned earlier.

An Entitlements Server typically performs the following functionality:

  • Separates security decision making from application logic.
  • Distributes policies from the PAP to the PDPs.
  • Caches policies and authorization decisions for performance.
  • Updates security policies at runtime.
  • Offers a flexible architecture that supports both embedded and remote PDPs (for centralized or distributed policy decisions).
  • Audits all access decisions and management operations.
  • Supports the XACML request / response protocol for authorization inquiries by a client application.
  • Integrates with existing security and identity management systems by leveraging enterprise data in relational databases and LDAP directories.

An Entitlements Server comprises centralized policy management with centralized or distributed policy decision-making. The architecture of an Entitlements Server is based on the interaction model of entities presented in the XACML specifications.

Entitlements Server Components
A typical Entitlements Server implements the XACML-based authorization model described earlier, including a PAP, which makes rules and policies available to the PDP in order for that entity to reach a grant or deny decision for a request to access the protected resource. The PAP generally includes an administration console, management application programming interfaces (APIs) dealing with resource and role catalogs, authorization and role- mapping policies, as well as management command-line utilities.

When the Entitlements Server is deployed, a PDP receives a request for authorization, evaluates the request based on applicable policies, reaches a decision and returns the decision to the PEP, the entity thatfirst made the authorization call. The PDP can also retrieve additional subject, resource, action, and environment attributes from a Policy Information Point to add contextual information to the request.

The PEP is a software component that intercepts the request to the protected application, passes it to the PDP and enforces the security decision returned from the PDP (the PDP may also return information with the decision [referred to as an "obligation"] that allows that decision to be enforced within a particular context). The PEP component can be the protected application itself or a "security module."

The Entitlements Server may offer two types of security modules. One type acts purely as a PDP by receiving requests and reaching decisions. The other type combines the PDP and PEP functionality. Security modules can accommodate various operating environments such as Java and Microsoft .NET applications.

The Attribute Authorities component illustrated in Figure 1 is in effect the PIP. Attribute retrievers are available for LDAP and relational database data sources.

Advanced Entitlements Servers implement the PEP Decision API, a part of the OpenAZ framework [3]. The OpenAZ package provides access from a PEP to a remote or embedded PDP.

Entitlements Server Policies
An Entitlements Server may support the creation of authorization policies and mapping policies. An Authorization Policy is created to return a decision ("grant" or "deny") as a result of a request for access to a protected target resource. The decision is based on the profile of the requesting principal (e.g., a user). An Authorization Policy is applicable to a request for access if the parameters in the request match those specified in the policy.

Consider this policy syntax:

GRANT the Support_Manager_East role MODIFY access to the Incidents servlet if the request is made from an IP address of 100.100.20.20

This Authorization Policy grants any user that is a member of the Support_Manager_East role access to the Incidents servlet for the purpose of modifying it. The policy is also constrained by a condition: the request must be made from IP address 100.100.20.20. Thus, if the parameters in the request match the parameters in the policy, and the request is made from IP address 100.100.20.20, the request is granted, otherwise the policy is ignored.

A Role Mapping Policy allows you to dynamically assign (grant) role membership to a user or dynamically deny (revoke) role membership from a user. A Role Mapping Policy defines which users or External Roles are mapped to an Authorization Policy. Role Mapping Policies are written to define which subjects (user and external roles) are assigned to the applicable role. They may also include conditions, i.e., constraints that must be evaluated to true for the policy to be included in the authorization decision.

Consider the following policy syntax:

GRANT the Employee group Application Role Support_Manager_East if the request is made from an IP address of 100.100.20.20

This policy grants the Application Role Support_Manager_East to any user that is a member of the group Employee. The policy is constrained by a condition: the request must be made from IP address 100.100.20.20. Thus, if the parameters in the request match the parameters in the Role Mapping Policy, and the request is made from IP address 100.100.20.20, the Application Role is granted otherwise the Role Mapping Policy is ignored.

Conclusion
An Entitlements Server allows enterprises to externalize fine-grained authorization from an application's logic, thus allowing developers to focus on business logic and leave fine-grained authorization decisions to security administrators.

References

  1. NIST: The National Institute of Standards and Technology (NIST) Computer Security Division (CSD) provides standards to protect information systems against threats to the confidentiality and integrity of corporate information.
  2. XACML: The Access Control Markup Language (XACML) describes a policy language (general access control requirements) and an access control decision request / response language. The RBAC Profile of XACML specification defines a profile for the use of XACML in expressing policies that use role-based access control (RBAC). In this case, RBAC "roles" are expressed as XACML Subject Attributes. For example, a specific XACML Permission PolicySet contains the permissions associated with the RBAC Manager role.
  3. OpenAZ: The Open Authorization API (OpenAZ) provides a standard interface between an application and a general authorization service. It also provides an effective way to enable authorization providers to plug in client-side authorization functionality.
  4. Oracle Entitlements Server: Oracle Entitlements Server (OES) is a fine-grained authorization management solution that externalizes and centralizes administration of enterprise entitlements, simplifies authorization policies, and enforces security decisions in distributed, heterogeneous applications.

More Stories By Marc Chanliau

Marc Chanliau has been in the software industry for more than 20 years and is currently a director of product management at Oracle where he is responsible for Identity Management solutions and innovations. He is heavily involved in security and XML standards groups including serving as the first chair person of the OASIS Security Services Technical Committee (SSTC), which culminated in the adoption of SAML as an official OASIS standard, participating on the WS-Security Technical Committee, helping to define the Liberty Alliance 2.0 specifications, and participating in the Java Specification Request (JSR) committee.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.