Joan A. Smith
Professor Dr. Stewart Shen
Old Dominion University
CS 519: Internet Databases
25 April 2003
XACML: Implementing Security Policy Through a Mark-Up Language
Implementing a security policy is currently a complex and error-prone exercise for an enterprise. The variety of access permissions that are required for normal functioning of a company's Internet commerce server may be radically different from its email or groupware servers. Each application within these domains typically has a unique way of setting the security levels, and these may vary on the deployment platform. OASIS has offered XACML (Extensible Access Control Markup Language) as a solution to the security policy (authorization) problem.
XACML provides a method for defining security rules in an XML format. It enables an organization to allow multiple layers of access authorization both within a document as well as for the document as a whole. This paper discusses the XACML specification, related XML security components, and currently available XACML software. It also reviews developer toolkits, and looks at issues that may affect broad-based utilization in industry.
While computer use has grown exponentially over the last few decades, the problem of maintaining data security has outpaced that growth. A truly productive business environment nearly always involves employees sharing documents created under a variety of application systems, operating systems, and (often) dispersed geographic locations. Like Automated Teller Machines, organizations need to allow access in a convenient manner to the right users while making it impossible, or at least incredibly difficult, for an unauthorized user to gain entry.
Policies have always existed at the physical level of a business: Employees might punch time cards, sign in with the receptionist, swipe a pass-card, or have a key to the building. Office doors may be locked, safes have secret combinations or closely held keys, and the checkbook is off limits to all but the authorized check writers. Translating this visible security layer into an effective policy at the digital layer is not a straightforward task. Consider, for example, that an on-line shopping cart is equivalent to a store patron ringing up his own purchases at the checkout counter. The business owner needs to ensure that the right prices are entered, that the credit card is valid and that it is being used by the credit card holder or authorized user.
Within an organization there are typically several layers of access in effect. This holds true whether it is to the physical plant or to the digital domain. An employee fills in and signs his own time card; a supervisor approves and co-signs many. The software project lead integrates multiple subprojects while a team programmer codes only his subroutine. But what about the varying levels of access to other documents, programs, databases and general digital resources distributed throughout the corporate core? Will “Joe’s” lunchtime hobby of web-surfing result in the Nimda virus infecting the entire corporate network? Containing that potential “bomb” could pose problems for a business that uses file exchange between corporate offices. “If there's one thing that computers do well, it's to make the same mistake uncountable times at inhuman speed.”1
The issue, then, is to find a way to comprehensively address the requirements of digital security for the enterprise as a whole - just as a physical security policy adapts to a new office building, the hiring and firing of employees, and so on. Ideally, the solution would be understandable and adaptable regardless of the types of applications, networks, and documents involved. This is the goal of the Extensible Access Control Mark-Up Language, XACML. “If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems.” 2
II. The XACML Specification
Version 1.0 of the XACML specification was published as an OASIS standard on 18 February 2003 after a brief public comment period.3 Several major corporations participated in its development, among them Sun, IBM, and Entrust. OASIS, the Organization for the Advancement of Structured Information Standards, is an international, non-profit group whose goal is to guide and sponsor the development of interoperability standards. Members and partners of OASIS include some of the largest and most influential corporations of the modern era (Hewlett Packard, Microsoft, and Intel, for example) as well as government organizations like NATO and the Federal Reserve System. Because of this, their recommendations and documented Standards carry considerable weight in the electronic information systems world.
An extension of XML, XACML has a tag-based format that follows its parent markup language, as this example of a policy declaration illustrates (adapted from Sun4):
<!—Applies to: CorpMainServer only -->
<Rule RuleId="LoginRule" Effect="Permit">
<!— sample comment text -->
The above is an abbreviated example; in practice, there are several other tags that are required between the starting and ending Rule tags, including Target, Subject, Resource, and Action tags. All tags are in the standard XML-style (e.g., <Target>.... </Target>).
XACML is based on the idea that there are 3 main components in the enterprise security model: policies, requests, and replies. The first component, Policy, represents the authorization scheme of the organization. It defines who has authorization; what they have access to; and when access is allowed (under what circumstances). It is analogous to one line of a company’s security policy such as “Only Employees from the Research Department may log into the Company Library Server after normal business hours”. XACML Policy statements, integrated via a “Policy Combining Algorithm,” make up a Policy Set. In this example, the Policy Set might include all of the company’s Intranet access statements.
A policy, in turn, is made up of a target, one or more rules, and (optionally) one or more obligations. The “target” is comprised of a subject, a resource, and an action. For our example here, the subject might be “employee”, the resource would be the library server, and the action would be “permit”. In the above example, this policy may have only two rules: First, the rule that examines the time of day and second the rule that compares the employee’s department. (This example assumes a different policy has covered basic employee login authorization). A “Rules Combining Algorithm” puts these two together, forming the Policy, which lets any employee login to the Library Server during the day, but only Researchers to login at night. Rules have effect(s) and, optionally, condition(s). “Effect” is typically “permit” or “deny”, thus enforcing an access rule. “Conditions” in our example here might be “time of day is night hours” or “employee is part of research department.”
Combining XACML with plain language, here is what this policy might look like in simplified form:
< Policy PolicyId=“ResearchServerAccess”>
<Rule RuleId= “DayTimeHours” Effect= “Permit”>
<Rule RuleId= “NightHours” Effect= “Deny”>
Condition= “Is Not Research Employee and time is between 8 a.m. and 8 p.m.”
Notice that the first rule has no conditions imposed. The result is that permission is granted to any employee if the access is occurring outside of night hours. (Our earlier caveat was that other “Policy Sets” handled the question of the login being by a valid employee in general). For the second rule, XACML would return an effect of “Deny” whenever the ‘night hours’ condition was not met. Employees can thus login during day hours, but only researchers can login at night.
The process of checking the rules and evaluating “permit” or “deny” effects is handled through the request and response components of XACML. An employee attempting to login to the Library Server would generate a XACML request document containing the Subject (employee’s ID, perhaps); the Action that is desired (login, in this case); and the Resource (Library Server) being requested. A Policy Enforcement Point (PEP) is the route through which the request is made and the response is returned. The following data flow diagram, taken from the latest published standard, 3 shows the relationship between Policy Access Points (PAP), Policy Decision Points (PDP), and the Policy Enforcement Point.
From the diagram the pivotal role of the PEP is clear. An important point is that “PEP sends the request for access to the context handler in its native request format.”3 It is the context handler that converts the request into XACML and later translates and returns the response to the PEP. If the result is “Permit” then permission is granted on the resource.
XACML’s role is limited to policy definition and its enforcement within the organization (or inter-organization in a B2B case). Other technologies must be included at the network and transport layers to manage user authentication and ensure privacy.
III. Related Technologies & Specifications
Obviously, there are other security aspects that need to be handled before the user reaches the system login dialogue. MIT’s Kerberos, for example, uses secret keys (cryptographic-based) to authenticate users. Its encrypted key exchange can solve problems like packet-sniffers trying to steal user login information. In this case, XACML would complement a Kerberos-based user authentication scheme rather than replace it, since XACML itself is not based on secret-key cryptography and Kerberos is not designed to articulate corporate security policy. The Kerberos protocol (specification) can be found at MIT’s web site 5.
There are several related specifications that can be combined with XACML to provide a comprehensive business-to-consumer and business-to-business security framework, such as the Security Assertion Markup Language (SAML). “The primary goal of SAML is to enable interoperability between different systems that provide security services. The SAML specification does not define any new technology or approaches for authentication or authorization. Rather, it simply defines a common language for describing the information or outputs generated by these systems in XML.”6 SAML’s main purpose is to provide a framework for business-to-business secure data accessibility.
Other XML-derived specifications include XML Signature, XML Encryption, and XKMS (the XML Key Management Specification). XML Signature “defines how to represent digital signatures in XML, providing the capability to digitally sign entire documents or specific sections.”7 The Network Working Group has published a Request For Comments which details the proposed XML Signature specification.8 A similar specification, XML Encryption, deals with the issue of document encryption, both in whole and in part. According to Mactaggert, “it is increasingly necessary to… encrypt and authenticate in arbitrary sequences, and to involve different users or originators.” 9 XACML, combined with XML Signature and XML Encryption, addresses this need for a more granular solution.
Lastly, the XKMS (XML Key Management Specification) “defines how to register and distribute public keys, addressing the key distribution problems in transactions where the parties have not previously communicated.”7 Although XKMS is not yet a published standard, it has the active development support of such industry heavyweights as Microsoft and Verisign. An XKMS Technical Note (the first step toward publication as a standard) was released in 2001. 10 No update has been published as yet, but vendors providing non-normative toolkits include Verisign, Microsoft, and Entrust.
IV. XACML Software
There are several products available for XACML developers at this time that adhere to the current published standard. Based on Java, Sun’s XACML toolkit is designed to “run on any compliant implementation of the Java 2 Platform, Standard Edition version 1.4 or later.”4 Another product, by Jiffy Software, is written in C++ and has platform-specific releases. Currently, Jiffy offers versions for Linux and for Microsoft’s XP platform. One potential problem with this product is that the supporting libraries are not in production. Developers are cautioned against replacing existing data link libraries with those that are needed for XACML development.
The third product is from IBM, and has been available since 2001. It offers an integrated XML Security Suite product that “provides security features such as digital signature, encryption, and access control for XML documents.”11 As such, it provides a more complete environment for an IT manager who is looking to prototype an XML-compliant security system. This toolkit is also Java based and has been top-rated by a major reviewer of Java software.12
Phaos Technology also offers a set of XML development tools (Phaos XML, Phaos XKMS, Phaos SAML and Phaos Security) that adhere to the various W3C specifications. This software suite has been used by NIST and is also Java-based. Other vendors are expected to release XACML tools soon, now that the first version of the standard has been published. Finally, OASIS has published a short, non-normative implementation guide for developers. It is extremely sketchy at this time, and the organization is soliciting contributions from developers as well as committee members.
V. Implementation Issues
There are a number of issues facing adoption of XACML in industry. Foremost of these is the formulation of a comprehensive security policy. Even though corporations typically have detailed handbooks describing the employee activities and duties, for example, this is often not the case for its digital environment. A statement, “the front door will be locked between 5:00 p.m. and 9:00 a.m.” may be in the company handbook. An equivalent statement, “Library Server Computer is only available to Research department employees” may not actually be written anywhere. Plain-English verbalization of digital security rules must be accomplished before they can be implemented.
Once the security plan is stated, it then needs to be converted to XACML. Each policy must be formulated in XACML and combined into appropriate policy sets. These, in turn, require the rules, targets, and other XACML elements as described above. For a large organization with many resources and levels or types of access permission, the task is quite daunting.
From this it is easy to see that the cost to implement such an approach would be high in terms of manpower, if not software. A small company, just reaching the point where security needs to be formally addressed could take this approach with an eye toward long-term savings. Once a XACML scheme is in place, updating it should be less resource-intensive. At least, that is the goal of the XACML software vendors.
But there are other issues, too. XML, from which XACML is derived, is still in the maturation phase, at least as far as its real-world utilization is concerned. According to Alan Kotok, a GAO report in 2002 cautioned that, for XML, “no consensus has yet developed for the standards to address the first group of basic cross-industry business functions.”13 A report by Larry Lange claims that company spending on security as a whole is lower than it has been in past years, even though the awareness of risk has grown.14 Proving the return on investment value for a technology still undergoing maturation will be a challenge for IT managers. As a result, it is likely to be a while before XACML is commonly used in businesses to manage security policies.
It is probably too early for most companies to begin the XACML conversion process except at an experimental level for a small project. Among W3C’s stated goals for the Extensible Markup Language are that it will be easy to write XML documents and also easy to write the programs to process them.15 Unfortunately, this is not the case for XACML. Vance McCarthy quotes one of the XACML committee members as saying: "Its verbose syntax make it hard to read and tedious to edit for other than very simple policies."16 Since the tools themselves are still in the early stages of development and release, businesses are likely to find the process difficult and expensive.
XACML offers an interesting solution to the problem of applying a comprehensive digital security policy to diverse applications, systems, and files. No competing approach has surfaced as yet to address this issue. Its compliance with the XML standard, and integration with supporting security technologies such as SAML, suggest that XACML has the potential to be the ‘Netscape’ of tomorrow’s corporate security policies.
1. Coffee, Peter. Security’s Language. eWeek 21 April 2003. Ziff-Davis Media.. Available at: http://www.eweek.com/article2/0,3959,1036787,00.asp Accessed: 21 April 2003
2. Cover Pages. Public Review for OASIS Extensible Access Control Markup Language (XACML) Specification. 8 November 2002. OASIS. Available at: http://xml.coverpages.org/ni2002-11-08-a.html Accessed: 15 April 2003.
3. Godik, Simon and Tim Moses, Editors. Extensible Access Control Markup Language Version 1.0. 18 February 2003: 19. OASIS. Available at: http://www.oasis-open.org/committees/xacml/repository/oasis-xacml-1.0.pdf Accessed: 14 April 2003.
4. Sun Microsystems. Sun's XACML Implementation. 13 March 2003. SourceForge.Net. Available at: http://sunxacml.sourceforge.net/ Accessed: 14 April 2003.
5. MIT (Massachusetts Institute of Technology). Kerberos 5 Release 1.2. 9 April 2003. MIT. Available at: http://web.mit.edu/kerberos/www/krb5-1.2/index.html - documentation Accessed: 18 April 2003.
6. Netegrity, Inc. SAML Knowledge Center. Netegrity. Copyright 2001. Available at: http://www.netegrity.com/products/index.cfm?leveltwo=SAML Accessed: 20 April 2003.
7. Evers, Joris. Secure Web Services Start With XML. InfoWorld 10 January 2002. International Data Group. Available at: http://www.infoworld.com/article/02/01/10/020114tcsecure_1.html Accessed: 14 April 2003.
8. Eastlake, D., J. Reagle, and D. Solo. (Extensible Markup Language) XML-Signature Syntax and Processing. March 2002. Network Working Group. Available at: http://rfc3275.x42.com/ Accessed: April 18 2003.
10. W3C (World Wide Web Consortium). XML Key Management Working Group. 10 April 2003. W3C. Available at: http://www.w3.org/2001/XKMS/ Accessed: 18 April 2003.
11. IBM (International Business Machines). XML Security Suite. 29 January 2003. AlphaWorks. Available at: http://www.alphaworks.ibm.com/tech/xmlsecuritysuite/ Accessed: 20 April 2003.
12. EarthWeb. JARS: Java Applet Rating Service. 15 April 2003. Jupiter Media. Available at: http://www.jars.com/listing/jars_top5_001.html Accessed: 18 April 2003.
13. Kotok, Alan. Government and Finance Industry Urge Caution on XML. 24 April 2002. O’Reilly & Associates. Available at: http://www.xml.com/pub/a/2002/04/24/gaonacha.html Accessed: 15 April 2003.
14. Lange, Larry Security Fears Are Up, So Why Is Spending Down? Available at: http://www.techweb.com/tech/security/20021106_security Accessed: 15 April 2003.
15. W3C (World Wide Web Consortium). Extensible Markup Language (XML) 1.0 (Second Edition). 6 October 2000. W3C. Available at: http://www.w3.org/TR/REC-xml#sec-origin-goals Accessed: 14 April 2003.
16. Open Enterprise Trends, Inc. XACML – A No Nonsense Developer’s Guide. 3 March 2003. Open Enterprise Trends. Available at: http://www.oetrends.com/cgi-bin/page_display.cgi?180 Accessed 18 April 2003.
Andress, Mandy. The Road To Secure Web Services. InfoWorld 10 January 2002. International Data Group. <http://www.infoworld.com/article/02/01/10/020114tcsecure_1.html>
OASIS. XACML Implementers Guide Informational Document 1.1. 11 March 2003. OASIS. <http://www.oasis-open.org/committees/xacml/repository/xacml-implement-guide-1.1.doc>
Jiffy Software, Inc. Jiffy XACML. 2003. Jiffy Software. <http://www.jiffysoftware.com/xacml/>
Krill, Paul. Sun Hails XACML. InfoWorld 18 February 2003. International Data Group. <http://www.infoworld.com/article/03/02/18/HNXxacml2_1.html?standards>
Mactaggart, Murdoch. Enabling XML Security: An Introduction to XML Encryption and XML Signature. September 2001. IBM. <http://www-106.ibm.com/developerworks/xml/library/s-xmlsec.html/index.html>
Phaos Technology Corporation. XML Security. 2003. Phaos Technology. <http://phaos.com/products/category/xml.html>
Sun Microsystems, Inc. Sun's XACML Implementation Programmer's Guide. 7 February 2003. Sun Microsystems. <http://sunxacml.sourceforge.net/guide.html#using-pdp>
Webservices.Org, Inc. XACML Ratified As OASIS Open Standard. 18 February 2003. Webservices.org. <http://www.webservices.org/index.php/article/articleview/909/1/65/>
W3C (World Wide Web Consortium). XML Key Management Specification. 30 March 2001 W3C. <http://www.w3.org/TR/xkms/>
|Site comments or problems: email joan smith|