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.
More
Computerworld
QuickStudies
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.")
Strengths
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 Inc. 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.
History
XACML was developed by a team that included people from Entrust Inc., IBM, OpenNetworks.org, Quadrasis Inc., Sterling Commerce Inc., Sun and BEA Systems Inc.
In February, XACML was adopted as a standard by the Organization for the Advancement of Structured Information Standards.
Kay (russkay@charter.net) is a Computerworld contributing writer in Worcester, Mass.
 |
|
|
The Web Services Tsumani
Stories in this report:
- The Web Services Tsunami
- The Story So Far: Web Services
- Web Services: Waves of Change
- Opinion: Web Services' Sharp Edge
- Web Services in Action
- A Plain-English Explanation of XML and Web Services
- Testing: Key to Web Services Success
- The Almanac: Software Development and Web Services
- XACML
- Preparing for a Career in Web Services
- The Next Chapter: Web Services
- Testing in an Organic World
- Use All Three Parts of Project Estimation
- Treat IT Applications Like Employees — As Ongoing Investments
See additional Computerworld QuickStudies