XACML tutorial: Using XACML as a foundation for entitlement management

Learn how to use XACML to externalize fine-grained authorization from application logic and support cloud-based IAM initiatives.

The identity and access management (IAM) landscape continues to evolve, with a number of trends shaping the technology at any given time. Just a few of the current trends affecting IAM architectures include “push-versus-pull” identity architecture, SaaS provisioning, Identity as a Service and service-oriented security.

By leveraging XACML, developers can remove the authorization logic from their applications.  Policies are centrally managed and can be modified based on business needs at runtime without any changes to application code.

In this brief XACML tutorial, let’s look at how an enterprise can externalize fine-grained authorization from application logic and provide a foundation to support emerging cloud-based IAM initiatives using eXtensible Access Control Markup Language (XACML).

The current state of authentication and authorization
Web access management has matured dramatically over the past decade. Many enterprises have separated Web-based authentication and coarse-grained authorization logic from their applications by successfully implementing single sign-on systems. These organizations are reducing operational costs, increasing end-user and application developer productivity, and satisfying many audit and governance requirements. Multifactor and adaptive access management technologies have been readily integrated into many organizations’ existing Web access management infrastructures to provide enhanced security and compliance.

When observing the benefits of centrally managed Web authentication security policies, a discrepancy emerges with regard to how organizations manage fine-grained authorization policies. This is exacerbated by ever-increasing internal threats to data security and evolving mandates to improve audit accountability and compliance reporting.

To conquer these challenges, organizations must move to a model of externalizing application authorization decisions, rather than just authentication and coarse-grained authorization. Fortunately, a mature standard framework exists for this purpose: OASIS XACML.  The XACML framework provides a reference architectural model, a policy language and a request/response decision protocol. Software vendors have provided technologies that adhere to the architectural model while offering user-intuitive tools for writing purposeful policies.

Externalizing authorization from applications
Many applications today are written with authorization logic built proprietarily into the application.  This logic, often driven by sustainable ACL and RBAC policy models, is often not reusable between applications. Development teams are forced to reinvent the wheel and spend measurable time maintaining business authorization rules, rather than focusing their efforts on core application development. Additionally, accurate reporting can be a time-consuming task when IT governance teams are tasked with tracking down exactly what access an entity has at any given time across several siloed applications. This becomes a nightmare in the event of a security breach. How quickly can you react and assess the scope of the breach?

By leveraging XACML, developers can remove the authorization logic from their applications.  Policies are centrally managed and can be modified based on business needs at runtime without any changes to application code. 

Overview OF XACML reference architecture
Policy Administration Point (PAP) -- Used to create, modify and distribute polices

Policy Enforcement Point (PEP) -- Logical point in application where authorization decisions are enforced

Policy Decision Point (PDP) -- Evaluates and issues authorization decisions

Policy Information Point (PIP) -- Requests data from each attribute source (LDAP, DB, etc.) and passes information back to PDP

Implementation strategy considerations
A real world implementation may feature the following teams with associated responsibilities.  This list is not inclusive of all responsibilities required to maintain an external entitlements management architecture, nor will the team names and structures be the same (or even remotely similar) in all organizations. This list is provided as a reference point to highlight major considerations that must be made and expose the cross-functional teamwork required to be successful.

  • Enterprise architects -- Responsible for determining how best to implement the XACML reference architecture in relation to application needs. Should the PEP and PDP be embedded in the J2EE container? Or can the PEP make calls to a distributed PDP
  • Infrastructure team -- Responsible for implementing the XACML reference architecture in a highly available manner. Does the infrastructure support performance and scalability requirements of a growing application base? Is the PIP deployed in such a way that all entitlement attribute sources, such as databases, LDAP and Web services are accessible? Is there a justification for a virtual directory between the PIP and attribute sources? Does it make sense to scale the infrastructure with advanced caching mechanisms and a private cloud?
  • Development teams -- Responsible for referencing the PEP, thereby removing hardcoded logic.  Shares a responsibility for ensuring previous business authorization logic is adequately translated to attribute-based access control (ABAC) polices within the PAP. ABAC can leverage existing RBAC and ACLs.

Security team -- Responsible for maintaining policies in the PAP. Will business units submit policy requirements to be translated, or will business units have delegated administration over their respective policies?

Governance team -- Responsible for the integrity of PAP policies. Do policies accurately reflect an organization's authorization requirements? Legal obligations? Are adequate controls in place? Are tools in place to quickly attest "who, what, when and where?"

To plan, scale and support an XACML architecture, all of the questions posed above and many more must be sufficiently addressed. Successfully externalizing authorization from a single pilot application will help answer each of these questions and help pave the way for widespread adoption of an enterprise's shared authorization service.

XACML tutorial: Conclusion
By embracing the XACML standard and taking a methodical approach to externalizing application authorization, enterprises will be better prepared to implement emerging trends as they mature and become reality. This low hanging fruit approach can be a first step towards an enterprise's adoption of more broad Security as a Service objectives. XACML will be a steady force in the future of SaaS provisioning, "push" vs. "pull" identity architectures and general federation in the cloud. 

About the Author:
Ryan Blain is a Delivery Manager at Solstice Consulting. Ryan has focused on identity management with over 10 years of experience in enterprise information technology as an industry information and data security expert, architect, and technical team leader. Ryan is experienced in architecture, design, and hands-on deployment for large clients in financial services, telecommunications, manufacturing, transportation, media, healthcare, insurance, higher education, defense, and federal and state government.  His subject matter expertise includes identity and application access management, enterprise single sign-on, provisioning solutions, LDAP, virtual directory services, identity federation, and data privacy.

This was first published in September 2011

Dig deeper on Enterprise User Provisioning Tools

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close