XACML Vendor: eNitiatives

This is a new series of posts where I interview XACML vendors. The first one that was kind enough to participate was eNitiatives.

Why does the world need XACML? What benefits do your customers realize?

Our primary customers are in Government, Defense, Intelligence, Telecommunications, and Health, with some key multinationals. All of these customers are concerned about providing fine grained authorizations for controlled access to digital assets. In the Defense, Government, and Intelligence sectors this is especially critical.

What products do you have in the XACML space?

We have two current products where we have implemented XACML, and one upcoming:

  1. Firstly we have ViewDS. This is our LDAPv3, X.500 and ACP 133(D) Directory server. Here we have built a PEP into our Directory server and use XACML to provide Policy Based Access Control to all data that we store within our Directory. Our Directory includes an Indexing and Search engine supporting 24 different types of searching and matching and fully supports XPath queries and can understand XML content.

    ViewDS has a Management Agent used to control and manage content in our Directory Server. In our latest release, it now has an inbuilt Policy Administration Point tool. ViewDS also has an inbuilt Policy Decision Point. ViewDS thus acts as both an Identity Store and a Policy Information Point as policies can be stored in the Directory schema and are treated as Directory Attributes. As well as XACMLv3, ViewDS fully supports RBAC, Label Based Access Control and Time Based Access Control

  2. Our Second Product is known as ViewDS Access Sentinel. Access Sentinel is an XACMLv3 Policy Decision Point designed to be used for externalizing authorization policy for external applications. Access Sentinel provides a combined PDP, PIP, two PAPs and a number of PEPs off the shelf. ViewDS Access Sentinel can use either ViewDS as its identity store, or an external LDAP Directory or Virtual Directory as its LDAP Identity Store.

    ViewDS also supports multiple schemas and with its inbuilt join engine, ViewDS Access Sentinel plus ViewDS Discovery server offers the capability to also join other data from external services. We have a number of PEPs available and will be announcing some new ones in our v7.3 release. We also offer a second PAP tool for providing fully delegated policy creation

  3. Also in our next release (ViewDS v7.3) we will be launching a third product: ViewDS Identity Bridge. ViewDS Identity Bridge is a bidirectional synchronization and provisioning engine. This will also support XACMLv3

ViewDS and ViewDS Access Sentinel are available for Oracle Solaris 11g, two versions of GNU/Linux and Windows Server 2008 and Windows 7. Other implementations on versions of UNIX are available.

What versions of the spec do you support? What optional parts? What profiles?

In ViewDS version 7.2 (the current release) we support the core specification minus XPath, the Administration and Delegation Profile, the Hierarchical Resource Profile, the Multiple Decision Profile, the Privacy Profile, the Intellectual Property Control Profile and the Export Compliance-US Profile.

An internal build of ViewDS Access Sentinel already supports XPath version 1.0, and we have now built support for XPath in our two XACML PAPs. This capability will be in the next release due out in September. The next release will also support the administration and delegation profile and the multiple decision profile. We are also looking at an implementation of the Export ITAR Profile for a specific US Customer. We are also considering the GeoXACML extensions.

What sets your product(s) apart from the competition?

Unlike other vendors we do not require an external database license such as SQL Server or Oracle to store policies or require an external server. Our PDP, PIP, Attribute Identity Store and PAP are all in the one platform.

This means our product performs well, as all activities are internal function calls. That is, there is no external processing. Because we treat XACML policies as standard directory attributes (ViewDS itself fully supports XML), we can use standard directory protocols to distribute policies which are kept fully in sync with the associated identity attributes. Our Policy Administration Point tools also allow the creation of policies without the need to write any XML and support a capability known as Named Expressions.

What customers use your product(s)? What is your biggest deployment?

All of our ViewDS customers worldwide (our product is in use in Defense, Intelligence, Government, Aviation, Health and multinational corporations with installations in 16 countries) that upgrade to ViewDS v7.2 released in March will have the full capability of XACMLv3 in this release. Roughly 30% of our customers have upgraded already. Our largest implementation covers 26M identities, but our product has been tested with up to hundreds of millions of entries.

ViewDS Access Sentinel was released 3 months ago as a stand-alone product. So far we have a small number of installations in Australia and North America in the Government and Defense sectors.

What programming languages do you support? Will you support the upcoming REST and JSON profiles?

For PEP development, in our V7.2 release we currently support C#/.NET. We now have a PEP library for Java complete but not yet released. This will be provided to customers for the v7.3 release due in September.

Our current plan is to support both the REST Profile and the JSON Profile. However, the REST draft is not publicly available, has not been listed in the working group’s deliverables and hasn’t even been accepted by the working group yet according to the draft itself. This Working Draft (WD) has been produced by one or more TC Members; but we understand has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft).

Do you support OpenAz? Spring Security? Other open source efforts?

We are currently involved with other XACML vendors (BitKoo/Quest/Dell and Axiomatics) led by Felix Gaethgens from Axiomatics in an open source effort that is getting underway to create a PEP API and implementation for XACML version 3.0 among other things. We are not involved in any other open source effort.

However, we partner with Ping Identity for integration of Authentication and Authorization.

How easy is it to write a PEP for your product(s)? And a PIP? How long does an implementation of your product(s) usually take?

We provide a C#/.NET library known as PDP Liaison and now have a Java equivalent available to allow application vendors to create PEPs in a matter of days. We are currently considering making these Open Source solutions.

We expect a customer to be live in test mode and creating policies in 3 days depending on whether they are using ViewDS as the Identity Store or an external Identity store such as Active Directory.

Can your product(s) be embedded (i.e. run in-process)?

The PDP runs in a separate process.

What optimizations have you made? Can you share performance numbers?

Performance will vary depending on the number and nature of the policies, but version 7.2 has been clocked at 3650 XACML authorization requests per second with a single quad-core Intel Xeon E5430 CPU at 2.66 Ghz.


XACML Supports All Major Access Control Models

In a previous post, I talked about one of the most advanced access control models to date: Risk-Adaptive Access Control. In this post, I will put this in context by taking a closer look at a variety of access control models.

Access Control Defined

Access control is all about permitting or denying access requests. An access request occurs when:
a given subject tries to access
a given resource to perform
a given action in
a given environment.

The NIST Survey of Access Control Models

The National Institute of Standards and Technology (NIST) issued a report that identifies the following access control models:

  • Access Control Lists (ACLs) (subject, resource, action, N/A)
    The subject is either a user or a group. In some cases it can be an application.
    ACLs are hard to maintain when many users share privileges. For example, all developers should have access to the source code management (SCM) system. If the SCM is upgraded with a new feature that has its own permission, then the ACLs for all developers must be updated.
    ACLs are widely available, for instance in operating systems.
  • Role-Based Access Control (RBAC) (role, resource, action, N/A)
    Users are now generalized into roles, like developer.
    Roles are often not granular enough. For example, only the developers for product X should have access to the product X SCM. This can be fixed by introducing finer-grained roles, but that often leads to an explosion of roles. Sometimes there are even more roles than users in a system!
    RBAC is commonly available, for instance in relational databases.
  • Attribute-Based Access Control (ABAC) (subject, resource, action, environment)
    Everything is now generalized into attributes. Environment attributes, like the current time, are now also supported.
    Attributes are often used differently in different applications. For instance, one application may name the attribute for role role, while another may use role-id. Or one application may use an ID into a role table as the value of the role attribute, while another uses the role’s human readable name.
    ABAC is considered state of the art.
  • Policy-Based Access Control (PBAC) (subject, resource, action, environment)
    Attributes are now harmonized across all applications of the (extended) organization. For instance, the Core and Hierarchical Role Based Access Control (RBAC) Profile for XACML defines the URN urn:oasis:names:tc:xacml:2.0:subject:role for the role attribute.
    We’re just starting to see some PBAC implementations.
  • Risk-Adaptive Access Control (RAdAC) (subject, resource, action, environment)
    The environment attributes now take on a much more important role. In particular, dynamic risk levels are encoded as attributes.
    I know of no implementations of RAdAC, but I think we’ll start seeing them soon(ish), since they can help in the fight against Advanced Persistent Threats.

Trends in Access Control Model Evolution

If you look closely at this mostly chronological development of access control models, you’ll find the following trends:

  1. Access control becomes more fine-grained
  2. Access control becomes more policy-based, less ad-hoc
  3. Access control becomes external to applications

XACML Supports All Major Access Control Models

The eXtensible Access Control Markup Language (XACML) is an OASIS standard for ABAC. Since ABAC is a generalization of RBAC, and RBAC is a generalization of ACLs, it’s not surprising that XACML can handle all of those access control models. Furthermore, PBAC is technically just ABAC. The PDP doesn’t care what attributes are used, or how they are named. Nor does it care whether does attributes represent dynamic risk levels, as in RAdAC.

So the conclusion is that XACML supports all the major access control models. This makes XACML a future-proof technology. It will easily accompany you on your journey to a more sophisticated access control model.