Maintaining security on their networks is critical for all companies. One primary tool that every network needs is access control -- the ability to carefully define and enforce which users have what type of access to specific applications, data and devices.
When the network was contained within a single building or campus, the problem was relatively simple and generally handled by software that was hooked into the operating system. But today's networks involve interconnected segments distributed across the country and around the globe, and many of these are also joined to the public Internet.
The growing use of XML as the common mechanism for exchanging data makes it simpler and easier to find and use data from external sources. Applications can call upon automated, remotely based Web services to add new capabilities. But who's in charge? Access control has become harder to manage at the very time it's more important than ever.
One answer lies with two specialized variants of XML -- Security Assertions Markup Language (SAML) and XACML. SAML defines how identity and access information is exchanged and lets organizations convey security information to one another without having to change their own internal security architectures. But SAML can only communicate information. How to use that information is where XACML comes in.
The language, which uses the same definitions of subjects and actions as SAML, offers a vocabulary for expressing the rules needed to define an organization's security policies and make authorization decisions. XACML has two basic components.
The first is an access-control policy language that lets developers specify the rules about who can do what and when. The other is a request/response language that presents requests for access and describes the answers to those queries.
XACML provides for fine-grained control of activities (such as read, write, copy, delete) based on several criteria, including the following:
-- Attributes of the user requesting access (e.g., "Only division managers and above can view this document.")
-- The protocol over which the request is made (e.g., "This data can be viewed only if it is accessed over HTTPS.")
-- The authentication mechanism (e.g., "The requester must have been authenticated using a digital device.")
XACML was designed to replace existing, usually application-specific, proprietary access-control mechanisms. Prior to the new language, every application vendor had to create its own custom method for specifying access control, and these typically couldn't talk to one another. The first implementation of XACML was created by Sun Microsystems in Java and is available at http://sunxacml.sourceforge.net. According to Sun, XACML has a number of advantages over other access-control policy languages:
-- Security administrators can describe an access-control policy once, without having to rewrite it numerous times in different application-specific languages.
-- Application developers don't have to invent their own policy languages and write code to support them; they can reuse existing, standardized code.
-- XACML is intended to be primarily a machine-generated language. XACML creators expect that easy-to-use tools for writing and managing XACML policies will be developed, since they can be used with many applications.
-- XACML can accommodate most access-control policy needs and also support new requirements as they emerge.
-- A single XACML policy can be applied to many resources. This helps avoid inconsistencies and eliminates duplication of effort in creating policies for different resources.
-- With XACML, one policy can refer to another. In a large organization, for instance, a policy for a specific site might reference both a companywide policy and a country-specific policy.
XACML was developed by a team that included people from Entrust, IBM, OpenNetworks.org, Quadrasis, Sterling Commerce, Sun and BEA Systems.
In February, XACML was adopted as a standard by the Organization for the Advancement of Structured Information Standards.
An XACML Glossary
Action: The type of access that is being requested (for example, read, write, create, delete, logged).
Attribute: A specific characteristic of a subject, resource, action or environment in which the access request is made. Attributes could include a user's name, workstation identity, security clearance, the file to which access is desired and the time of day.
Bag: An unordered collection of attributes, used for matching attributes to conditions. Bags may contain duplicate attributes or be empty.
Condition: A simple or complex Boolean function at the heart of a rule.
Effect: The result of an authorization: deny or permit.
Policy: A single access-control policy expressed through a set of rules.
Policy Set: A container of policies, including references to remote policies.
Resource: A device, data element or file for which access is requested.
Subject: The person or computer making a request.
Target: A set of simplified conditions for the subject, resource and action that must be met for a policy set, policy or rule to apply to a given request.