AX2E - AXESCON XACML 2.0 Engine (Beta version)

Welcome
FAQ
User's Guide
JavaDocs
Beta Tester User Group

Welcome to AX2E!

AX2E is a brand new implementation of the OASIS XACML standard, written in the Java^TM programming language. For more information about XACML look at a slightly outdated but still usefull "A Brief Introduction to XACML" , or the XACML TC web page. AX2E requires the Java 2 Platform, Standard Edition version 1.4.0 or later.

AX2E provides complete support for all the mandatory features of XACML 2.0 as well as a number of optional features. AX2E is built for easy extensibility and customization, through clearly defined public interfaces (APIs) and its component-based architecture. AX2E can be configured to use customized or completely new components, which can, for instance, implement new attribute data types or policy stores. AX2E passes all tests in current XACML 2.0 Conformance Test suite.

This project was developed in AXESCON LLC. Our primary expertise is in enterprise software development on J2EE platform with current focus on access control frameworks using XML-related technologies. If you'd like to employ our consulting services please mail to info@axescon.com.

Introduction to XACML

XACML (eXtensible Access Control Markup Language) is an OASIS standard for access control implementation. It defines XML-based security policy language as well as a model of data flow of authorization decision making. This model has an abstraction layer which allows easy customization to any particular environment.

This model is based on request/response paradigm. When a user tries to perform a given action on a given information resource, it's the task of PEP (policy enforcement point), protectig such a resource, to form a request for access to PDP (policy definition point). PDP finds applicable policies, then evaluates these requests. Finally, PDP send a response with a decision back to PEP. PEP may grant or deny access to a resource based on this response.

XACML standard defines XML schemas for policy language and for request/response language. Having the above mentioned abstraction layer, it's not necessary to have request/response and even policy actually written in XML. For example, it can be more effective to pass requests as Java objects to PDP, as long as these objects can be "logically mapped" to XACML Context schema. The same is true for policies and other elements of XACML standard.

Implementing XACML in the enterprise, several obvious benefits can be achieved:

Audit: isolation of access control logic from the rest of the application in secuirty policies allows for easier security audits, which is especially important for enterprises subjected to Sarbanes-Oxley regulations.
Administration and Audit: it's easier to maintain and audit secuirty policies when they are all written in one standard language.
Development: using XACML saves time by avoiding the necessity to develop custom access control language and authorization decision making code.