Introduction to XACML

Before we launch into the “how” of XACML, let’s ask the “why” question. It may not be immediately obvious what problem XACML is attempting to solve. In the case of SAML, information is being sent between different parties and therefore the parties must agree on a format for that data. If two companies disagree on how they will describe authentication and authorization events, then single sign-on is impossible because the companies are unable to express information about the security status of a user to each other. However, if these same two companies express their authorization rules differently, the picture is not so bad because these rules are generally not sent on the network, but are used in the background to express policy. Why, then, spend time producing a common XML format for authorization rules?

The answer is that XACML is useful as a policy exchange format, in order for systems to exchange or share authorization policies—even if the policies are translated into a proprietary or native policy language prior to the actual execution of the policy. XACML means that access control policies do not have to be tightly linked to the systems that they govern, but can be enterprise-wide across many different resources, including XML documents, non-XML documents, relational databases, and application servers. It’s another example of the advantages of XML being applied to security. Indeed, it can be argued that like XKMS, XACML is more about applying XML to security, rather than about applying security to XML. The documents accessed using a policy expressed in XACML do not have to be XML documents at all—and in the majority of cases they will not be XML.

XACML can best be understood in terms of the architecture of SAML. In the SAML chapter, we encountered the SAML protocol, using an authorization decision query to request a decision on authorization. In addition, an attribute query can be performed in order to find out information used to make an authorization decision. The information used to make these decisions can be expressed in XACML.

Basic Concepts of Access Control

In order to understand XACML, it’s important to understand the concepts of access control. There are two basic access control models that apply to systems on the Internet: access control lists (ACLs, sometimes pronounced “ack-els”), and, more recently, Role-Based Access Control (RBAC).

Access Control Lists (ACL)

In ACL, each username is mapped to a separate permission set for particular resources. This permission set includes the Read, Write, Execute, and Change permissions. This arrangement is sometimes called an “access matrix.” Examples of ACLs are found in UNIX and Microsoft Windows.

Role-Based Access Control

Role-Based Access Control (RBAC) has gained popularity in recent years, mainly because it allows access control to be performed by taking the context of users into account. Users can be put into groups, and assigned to “roles.” These roles can reflect organizational structure. For example, a user with a role of “doctor” can view certain documents, and another user with a role of “nurse” can view other documents. It is the roles that have the permission sets, not the users. A role can be created by inheriting one or more properties from other roles, which is reminiscent of the use of multiple inheritance (and interfaces, in the case of Java) in object-oriented programming.

Rules can also depend on factors such as time of day, so that a rule can be assigned to a user that links together the “doctor” and the “weekday access” roles. RBAC is less complex than ACLs because the size of the rule base increases in proportion to the number of roles and resources, not in proportion to the number of users. Therefore, it is generally believed that RBAC-based systems scale better than ACL-based systems.

As a side note, it is somewhat unfortunate that the use of the word “role” in SOAP 1.2 in place of “actor” has added another meaning to the word “role.” Role-Based Access Control focuses on the role of the user, not the role of the service processing a message. If the use of the phrase “SOAP role” gathers currency, it could spread confusion.