|
November 1, 2005 -
Today's enterprise is a fluid, dynamic, ever-changing organism, more agile and adaptable than at any other time in history. In other words, it’s an absolute nightmare for Security Officers, Compliance Officers, CIOs, and CFOs who are responsible for controlling access to resources.
Authorization and access control are critical considerations for every system, every transaction, and every interaction among individuals over the network today; yet the increasing diversity and dispersion of network elements and authorization technologies makes it extremely difficult to manage access effectively. At the same time, regulatory requirements such as Sarbanes-Oxley, HIPAA, the Gramm-Leach-Bliley Act (GLBA), and the EU Data Protection Directive make it more important than ever to keep sensitive documents private, protect trade secrets and intellectual property, ensure the security of systems and data, and avoid inappropriate information exchange with trade partners.
Standardizing a Solution: eXtensible Access Control Markup Language (XACML)
There has never been a shortage of access control solutions—and that is part of the problem. Multiple policy languages and formats have emerged over the years to control who is allowed access to what and under which conditions. Many of these languages are proprietary or apply only to specific applications, resulting in interoperability problems. Moreover, no current solution is adequate for the evolving world of inter-enterprise integration of supply chains, grid security, etc. None of the alternatives handles fine-grained access control for XML documents, which is important in complying with HIPAA and other regulatory requirements. What the marketplace has needed is a standard means of addressing access control and a standard that addresses the shortcomings and limitations of current solutions. And who better to lead the development of a standard than Sun, the guiding force behind many of the standards that prevail in the network computing arena today--from NFS and JavaTM to XML, JXTA, and the Liberty Alliance security specifications?
Sun’s involvement in the XACML standard began with the Internet Security Research Group at Sun Microsystems Laboratories (Sun Labs) in 2001. “As part of our research into building scalable authorization systems, we saw that the lack of a standard language was a real problem,” said Seth Proctor, a long-standing member of the ISRG. “Our goal was to develop a standard access control language that was platform-agnostic and application-agnostic so that other components of a distributed, interoperable authorization framework could make use of it.”
Today, thanks to the contributions of developers and researchers at Sun Labs, BEA Systems, Entrust, IBM, and many other individuals and organizations, XACML is an OASIS-ratified access control standard. XACML defines the syntax for a policy language (using XML) and the processing required to evaluate those policies. The policy language is used to describe access control requirements, and has standard extension points for defining new functions, data types, etc. A request/response language also defined in the XACML specification makes it possible to form queries to ask whether or not a given action should be allowed, and interpret the result. XACML was designed to accommodate most system needs, so it can serve as a single interface to policies for multiple applications and environments.
Sun’s implementation of XACML has now been available for more than two years. Launched as a ready-to-use release, it is now in version 1.2 and is mature and robust. Sun’s implementation of XACML is written entirely in JavaTM for easy portability and because JavaTM is an excellent platform for security, but according to Anne Anderson, another original member of the Sun Labs ISRG, “part of the beauty of XACML is that it is not tied to a particular language or platform. Implementations have been written in Java, C++, and even C#. They can be implemented on SolarisTM, Linux, or Windows.”
Sun’s XACML implementation continues to evolve as an Open Source project, available on sourceforge.net under a BSD license. For information about the implementation and the OASIS specification, go to ttp://sunxacml.sourceforge.net.
Fast-growing Portfolio of Real-world Applications
For security reasons, enterprises are frequently unwilling to publicize the security mechanisms they use internally, and many deployments of XACML fall into this category. However, a large and growing number of businesses, institutions, and university/research groups are now using XACML in their security systems. Just a few examples:
- Children's Hospital, Boston: The world's first personally controlled health record system, called Personal Internetworked Notary and Guardian (PING), enables a patient to own a complete, secure copy of her medical record, integrating health information across sites of care and over time. PING utilizes the XACML Library to implement the necessary authorization functionality.
- DataPower’s XS40 Security Gateway, a diskless networking device built to provide complete XML Web Services security, supports XACML among many other key security standards to provide a foundation for advanced benefits such as service virtualization and centralized policy management.
- Entrust is an active member of the OASIS Access Control Technical Committee working on XACML — acting as editor of the specification. Entrust GetAccess™ uses XACML to capture fine-grained entitlements policies in a standardized and interoperable syntax.
- FreebXML Registry Open Source Project (Electronic Business Registry/Repository). XACML is used for access control internally, so freebXML adopters are also XACML adopters.
- Jericho Systems: Jericho’s EnterSpace Security Suite (ESS) delivers an XACML-compliant, rules-based authorization service that can operate within an open standards-based SOA.
- Cardea (part of the NASA Information Power Grid): This distributed authorization system protects potentially accessed resources through local access control policies that are specified within the XACML syntax.
XACML in the Sun Service Registry
Sun's Service Registry, a shared component of the infrastructure in Sun’s JavaTM Enterprise System (beginning with Release 4 scheduled for Fall 2005), is the first Sun product to harness XACML. The Service Registry enables service-oriented architecture (SOA) and Web services projects by providing centralized access to discovery, use, and reuse of Web services, as well as secure federated information management. Using the Service Registry, Sun customers can publish, manage, govern, discover, and reuse services within a broad range of applications, so they can truly address both Web services access and SOA governance.
The Service Registry is based on a Sun-led open source implementation of the latest ebXML Registry standard (3.0) developed at SourceForge.net, and uses Sun’s implementation of XACML to provide access control functionality. “Sun’s implementation of XACML was chosen because it provided a full-featured access control expression language; it is a royalty-free Open Source project; and it has a healthy community of adopters and developers behind it,” said Farrukh Najmi, Federated Information Management Architect at Sun.
As a core, shared component, Service Registry will integrate with other key components of JavaTM ES (e.g., Application Server and Portal Server) to enhance overall SOA platform capabilities in both design-time and runtime uses.
XACML Evolution: What’s Next
As XACML continues to gain momentum in the development community, its own development is focused on supporting more control of policy administration and delegation of rights (or more sophisticated control of who is authorized to create certain types of policies), and generalization of XACML decision results. This generalization will allow XACML policies to include specification of one or more actions that must occur in a particular order when a policy is satisfied, rather than simply permitting or denying the requested action. The current release of XACML supports a simple form of this capability in the form of Obligations, but the current work seeks to extend and refine this capability.
At the same time, researchers are spending considerable effort trying to reduce the inherent complexity of authorization systems. Sun Labs, for example, is working with researchers at several universities on projects such as visualizing policy language to make it easier for administrators and non-technical businesspeople to understand what’s going on in the authorization system. “In the security world, you need to be very precise, but in the process of being precise you create a lot of complexity,” said Mr. Proctor. “The added complexity creates additional administrative requirements, which hinders overall scalability. So we’ve got to address the complexity issue.”
Mr. Proctor has a few simple words of advice for those who are interested in XACML. “Use it,” he said. “Learn more about it and try it. Early experiences using XACML have been very positive, and we’re confident it can play a role in better access control for all types of organizations.”
|
| Anne Anderson's new technical report -
"A Comparison of Two Privacy Policy Languages:EPAL and XACML"
- examines in detail the differences between the two languages.
|
|
The XACML Advantage
XACML is not in and of itself a complete authorization solution; rather, it provides a foundation upon which integrated solutions can emerge. It provides a host of advanced features that make it well suited for tying together large-scale authorization solutions. Among its many advantages compared with traditional proprietary languages:
It's standard. Because XACML is a ratified, standard language, developers who use XACML can take advantage of the collective experience of a large community of experts and users, so they don't need to roll their own system each time, and they don't need to think about all the tricky issues involved in designing a new language. Moreover, as XACML becomes more widely deployed, it will be easier to interoperate with other applications using the same standard language.
It's generic. This means that rather than having to provide access control for each particular environment or each specific kind of resource separately, developers can use XACML in any environment. One policy can be written that can then be used by many different kinds of applications, and when one common language is used, policy management becomes much easier.
It's distributed. This means that a policy can be written in a way that in turn refers to other policies kept in arbitrary locations. The result is that rather than having to manage a single monolithic policy, different people or groups can manage separate sub-policies as appropriate, and XACML knows how to correctly combine the results from these different policies into one decision.
It's powerful. While there are many ways the base language can be extended, many environments will not need to do so. The standard language already supports a wide variety of data types, functions, and rules about combining the results of different policies. In addition to this, there are already standards groups working on extensions and profiles that will hook XACML into other standards such as SAML and XML Digital Signature, which will increase the number of ways that XACML can be used.
|
|