The heart of entitlements management is the eXtensible Access Control Markup Language (XACML) protocol.

Editor’s note: This chapter is excerpted from chapter 4 of Identity Management: A Business Perspective.

This standard has moved access control ahead immeasurably. It provides the process and technology for IAM environments to provide tight control over a wide range of resources. The use of XACML can be illustrated as shown in Figure 4.7.

Figure 4.7: Use of XACML in an IAM environment

When a user accesses the application, the enforcement point (PEP) sends a decision query to the decision point (PDP), which sends an attribute query to the information point (PIP). The PIP looks up the user’s record in the identity provider service (typically a directory) and responds with an attribute statement. The decision point then sends a decision statement to the PEP for enforcement.

Request

The structure of a request has four components, as shown in Figure 4.8.

Figure 4.8: Structure of a request

The subject is the requesting entity. The resource is the application or documents to which the subject wants access. The action is the requested action, such as “view” or “write.” The environment attributes are optional and can be used to specify other things such as time-of-day restrictions.

In this example, Alice, whose record in the directory indicates she is a developer, wants read access to the Developer Guide in the “docs” directory on the company’s website.

Response

A response has three components, shown in Figure 4.9: the decision (hopefully permit), the status (should be OK), and any obligations on the decision (e.g., currency is in US dollars).

Figure 4.9: Components of a response

A permit response might look like the following:

Other supported responses are: deny if the policy conditions are not met, not applicable if there is no appropriate policy, or indeterminate if there is insufficient information to make a decision, in which case more information may be requested.

Making Policies

One of the big benefits that entitlements management offers its users is the centralization of policies.

In most companies, policies are implemented in a haphazard fashion that is focused on individual applications. For instance, access policy for the Finance application is managed separately from the HR system, which is separate from the enterprise resource management system. This renders policy management costly and generally ineffective without a herculean manual effort to consolidate access control policy.

Centralizing policy management means that all business units with an application to be controlled can administer policy that can be implemented uniformly across the company. Most solutions have a distributed management capability to support multiple administrators, but it is important that a centralized approach is taken to ensure policy governance.

The policy structure in XACML is quite structured. It consists of obligations— that is, conditions under which the policy is to be administered, target—that is, the resource under management, and rule(s)—that is, the effect of a policy evaluation.

An Example

A policy might be established to allow the finance manager read access to the general ledger, accounts payable ledger, and accounts receivable ledger for the purpose of monitoring and reporting. In this case, the components of the policy are the following, also shown in Figure 4.10:

• Target—defines the applicability of a particular policy
• Subject—typically the entity that is the subject of the policy
• Resources—G/L, A/P ledger, and A/R ledger
• Action—read
• Environment—additional attributes to manage the scope of a policy target

Figure 4.10: Components of a policy

There is an additional attribute set for policy purposes (e.g., monitoring and reporting).

Note: The policy administrator does not need to know how to format an XML file. The policy administration point (PAP) is equipped with a graphical user interface that generates XML code from English-language policy statements constructed with the help of pull-down menus.

Where to from Here?

So what’s holding us back from deploying APAM systems? Firstly, there’s the “if it’s not broken, don’t fix it” syndrome that encourages us to put up with less than optimal systems. Another detractor is the requirement for a mature identity management system in order to access attributes. There is also a need to manage policies: sometimes business groups are unwilling to take on the policy management task.

It’s incumbent on C-level management to grapple with these issues. They must set the strategy and implement the requisite change management. If they do, not only will they be reducing the risk profile associated with their access control system, they’ll open up new opportunities. It will be possible to more easily extend business system access to their business partners and potentially customers, for whom it is unsustainable to populate AD groups.

APAM has much to offer; we just need a willingness to embrace it.

Policy Management

A significant component of any ABAC environment is the requirement for a well-constructed policy management service. Most ABAC system vendors provide a policy administration manager (PAM) tool that facilitates the development and deployment of policies. There are several approaches to policy creation and management:

• The policy management console ships with predefined policies that can be configured to the organization’s system specification.
• The policy administration tool provides a GUI with pull-down menus to build simple custom policies.
• The policy administration tool provides a natural-language, dialog- builder policy editor for the construction of complex policies.
• A programming interface is provided to facilitate construction of XML

This is obviously an important differentiator between potential ABAC solutions, and it is directly related to the policy management approach that is to be adopted. If the business units within the business are to manage their own policies, the PAM must support a user-friendly approach; this will typically be a dialog- builder approach. If the company uses a policy administration unit staffed by specialists in policy management, a more technical approach can be adopted, and it is advisable that the unit have the capability to parse XML files.

Policy enforcement points can also be a challenge, particularly if there are many legacy applications to integrate. Old systems with built-in access control logic will need to be modified to externalize the authorization function and take advantage of the more fine-grained control that ABAC can provide. Vendors of ABAC software assist this development by providing software development kits and API code that facilitate making legacy apps entitlement policy-aware.

Policy decision point management can be complicated for distributed organizations or hybrid situations in which some applications are in the cloud. While policy management must remain centralized, the decision points will need to be distributed, and a mechanism to keep them current will be required.

Finally, policy administration must be addressed. With the movement of policy management from IT to business, business units must understand their requirements and be able to encode their requirements in policies. In some organizations, this is hard to achieve, and a centralized policy management facility, servicing multiple business units, is required.

It is also recommended that a common foundation of terminology and concepts be adopted in order to encourage the greatest level of interoperability possible. Adopting a standard such as XACML is highly recommended, even though most XACML deployments contain a degree of proprietary logic. Adopting a standard can facilitate the integration of products from multiple vendors.

Next time: Privileged Account Management. Want to learn more now?  Buy Graham's book today at the MC Press Bookstore.