XACML: Dead or Alive

In order to bring clarity of whether XACML is dead, some analysts have claimed, or alive, we need to first understand what XACML is and where it fits in.

First of all XACML stands for eXtensible Access Control Markup Language and is the current de facto standard for a declarative language to define access control policies. Its fully implemented in XML. Its an Oasis standard and XACML 3.0 was released in January 2013, and of course the idea behind a standard is to promote a common terminology and ensure interoperability between access control implementations independently from whatever vendor is behind a particular technology or solution.

A closer look at XACML shows that its primary aimed at attribute based access control systems (ABAC), where the foundation for policy declarations is based on attributes and their values, however Role Based Access Control (RBAC) can also be used in XACML as a specialization of ABAC. Despite the name “eXtensible” does XACML enable externalization and encourages the separation of access decisions via Policy Enforcement Points (PEP).

The primary idea behind externalizing authorization and access policies from applications, is to centralize access policy governance but the benefits can be seen in three different areas according to leading vendor and provider of XACML based solutions, Axiomatics.

• Software development: Policy Enforcement Points (PEP) are standardized components, intended to be re-used in software development and rather than implementing application specific logic in each application to determine what each user is allowed to do, PEPs make calls to a central Policy Decision Point (PDP). The end result of course is faster development and deployments.

• In software life-cycle management: Fundamental change requests with regard to entitlements – for instance to meet regulatory compliance requirements – are managed with centralized policies. There is no need to change configurations or functionality in individual applications or services.

• In operations: Entitlement-carrying attributes are widely managed in day to day line of business activities. Identity & Access Management solutions can to a large extent be embedded in existing business processes rather than demanding a separate administrative effort.

Now, having described the above, it is important to separate the “Externalized Authorization Management (EAM)” from the standard and language XACML.

EAM in the enterprise world is far from anything new and have been implemented in mainframes e.g. via RACF for decades. So just because enterprises are not leveraging XACML doesn’t mean they are not doing EAM.

Some of the arguments to why XACML has been declared dead, highlights poor adoption in a broad sense among large enterprises who written their authorization engines, that is not suitable for the cloud and distributed deployment, that refactoring and rebuilding existing in-house application is not an option.

As we all know, the current trend we are witnessing, is that APIs over the last few years are shifting more and more towards JavaScript Object Notation (JSON) in both responses and requests, which means that the more verbose XML notation is being dropped in favor of the less verbose JSON. Reason for that is of course the easy of use but also that all of the sudden we can reach better scalability when there is no need to parse XML. This would of course throw gasoline on the “XACML is dead” debate, but the community around XACML has been active working on JSON and RESTful bindings for XACML which will lead to increased XACML adoption - also lets not forget the OpenAZ project which moves forward in providing a vendor agnostic PEP API, open to anyone to use.

What about OPENAM and XACML?

• Import/Export tool for XACML policies
  XACML can be a medium both to transfer and store access control policies. In OpenAM the policies are stored in a proprietary format and its not using XACML per se to store the policies. Therefor policies needs to be converted to a native format for storage. Part of OpenAM, ForgeRock provides an Import/Export tool for XACML policies. More about that can be found in the documentation for OpenAM.

• Java SDK for XACML

OpenAM has an API available over Java to reach out to the XACML service however it currently only support XACML v2.

• XACML2 SAML profile

OpenAM provides the XACMLv2 query capability in the Fedlets.

When it comes to the management of fine grained entitlements in the form of a GUI, this is something that currently is on the roadmap for OpenAM and i know product management is looking into providing the support for XACML v3. What is known is that there is a business interest implying that XACML is far from dead from big enterprises and governments point of view.

One of the potential issues with XACMLv3 is the amount of traffic generated when having millions of policies that needs to be evaluated. OpenAM is built with performance in mind and clearly there needs to be efforts into making XACML v3 performing to the modern web especially if it should find a good fit inside OpenAM.

To conclude this post, I want to quickly deviate a bit from XACML. Recently I spent a lot of time at a large prospect customer whose entire Identity Management system was built up around SPML and we all know how people have been claiming SPML is dead. A key requirement for this prospect was to serve the current deployment and deliver the provisioning capabilities via SPML but rip out and replace the backend. They had no intention on changing this interface! Clearly SPML is not dead, and neither is XACML and i doubt XML would disappear anytime soon. More likely is the turkey dead going in the oven. Happy Thanksgiving!

Thoughts around Product Strategy

I have had reasons lately due to an upcoming workshop within my company, to give product strategy some thought. Product strategy is an important factor to the success or failure of a product or a suite of products and its important to stay on top of this, possibly fine tuning it to fit the needs of an identified customer base.

Setting a product strategy is a critical step when beginning the journey of a product or for that matter a set of products. The strategy defines and outlines the direction that needs to be taken but also the goal with a particular product.

Defining a product strategy is something that is part of the job as product manager and its necessary that this strategy answers some critical questions such as who will buy this product and why? What business problems and value does this product resolves for the customer buying it?

It is also however important to outline the minimal capabilities a product requires to fulfill customer needs, but also define the characteristics of why that product is better, or easier, or whatever unique selling point associated with the product might be.

The product strategy’s overall purpose is to help your company achieve corporate goals and therefore should be aligned to the corporate strategy. The corporate strategy should direct the goals for the product strategy. For maximum success, its extremely important that domain expertise is valued and is empowered by management within an organization developing a product. This is the job of the product manager. An unempowered product manager is a product manager that will struggle with his task. Ultimately the product will suffer and the team behind it will lose in morale. If the company strategy is weak in the sense of providing direction to product strategies, this may also impact the individual product strategies negatively.

Input should come from those able and capable of understanding the market segment. Getting good understanding of the competitive landscape is critical and its important to point out that this doesn’t not only applies to capabilities, features and ease of use etc but also to the pricing model as the basis for selling it.

Developing the product strategy, although owned by Product Management, involves multiple functions within the company and the close collaboration between these different functions. Often you will find conflicts between different functions which are necessary to be resolved or bridged. However, ownership should never be slipped into the hands of the others.

A product strategy should not be a 60 pages document outlining all details, but a message that answers the questions mentioned above in a concise and well articulated way and easy enough for everyone to understand to allow buy in. The roadmap and the execution or project plan is merely vehicles to reach the goal of the strategy, and if all goes well, the product provides a revenue stream for the company.

To conclude, that the most important factor around product strategy is to have empowered owners of the product strategy to allow for maximum buy-in from the teams developing, marketing, selling, deploying and supporting a product.

ForgeRock Common REST API overview

One of the unique features of the ForgeRock Open Identity Stack, is that all components of the stack share a single, easy to use RESTful web API. REST stands for Representational State Transfer and is a technique that relies on stateless, client-server and cacheable communication where the HTTP protocol is used. Not only is REST a more lightweight alternative to traditional SOAP based web services but given its HTTP nature, makes it easy to use in a firewall controlled environment.

The Open Identity Stack contains three different products, each with individual modules and capabilities; OpenAM, OpenDJ and OpenIDM. The Common REST or CREST can be used to access and leverage all the underlying modules and features with a set of easy to remember REST calls (CRUDPAQ).

Create Add a resource that does not yet exist	Patch Modify part of an existing resource
Read Retrieve a single resource	Action Perform a predefined action
Update Replace an existing resource	Query List a set of resources
Delete Remove an existing resource

OpenAM

OpenAM offers a RESTful API for authentication, logout, cookie information, token attribute retrieval and token validation, authorization, OAuth 2.0 Authorization, OpenID Connecto 1.0, self-registration, password management, managing identities, managing realms and logging.

OpenDJ

The present implementation in OpenDJ maps JSON resources onto LDAP entries, meaning REST clients can in principle do just about anything an LDAP client can do with directory data.

OpenIDM

OpenIDM provides an implementation that allows you to manipulate managed objects as well as system objects.

Interacting with the RESTful API

There are a number of ways and programming languages which you can easily interact with the ForgeRock Common REST API. An easy way to invoke REST calls is to get hold of a REST client that allows you to easily provide the necessary details, save calls and tweak them as you play with the interface. One REST client that often is being referred to in our documentation is CURL (http://curl.haxx.se). CURL is a command line tool for submitting data with URL syntax and free to use.

Some samples using ForgeRock Common REST

Lets retrieve a user from OpenDJ, authenticated as Stevie with password Wonder.

$ curl --request GET --user stevie:wonder http://opendj.example.com:8080/users/newuser?_prettyPrint=true {  "_rev" : "000000005b337348",  "schemas" : [ "urn:scim:schemas:core:1.0" ],  "contactInformation" : {    "telephoneNumber" : "+1 408 555 1212",    "emailAddress" : "newuser@example.com"  },  "_id" : "newuser",  "name" : {    "familyName" : "New",    "givenName" : "User"  },  "userName" : "newuser@example.com",  "displayName" : "New User",  "meta" : {    "created" : "2013-04-11T09:58:27Z"  },  "manager" : [ {    "_id" : "opope",    "displayName" : "Olivia Pope”  } ] }

In OpenIDM we can simply create a new user using

$ curl --header "Content-Type: application/json" --header "X-OpenIDM-Username: openidm-admin" --header "X-OpenIDM-Password: openidm-admin" --request PUT --data '{ "userName":"joe", "givenName":"joe", "familyName":"smith", "email":"joe@example.com", "phoneNumber":"555-123-1234", "password":"TestPassw0rd", "description":"My first user" }' http://localhost:8080/openidm/managed/user/joe

In OpenAM we can perform an authentication with the following call:

$ curl --request POST --header "X-OpenAM-Username: demo" --header "X-OpenAM-Password: changeit" --header "Content-Type: application/json" --data "{}" https://openam.example.com:8443/openam/json/authenticate { "tokenId": "AQIC5w...NTcy*", "successUrl": "/openam/console" }

The above are just three simple calls to showcase the easy of use and flexibility of the Common REST API the Open Identity Stack offers. Check out the suggested reading links for more samples and information on how to leverage the capabilities exposed by the API.

Suggested reading

OpenAM:

http://docs.forgerock.org/en/openam/11.0.0/dev-guide/#chap-rest

OpenIDM: http://docs.forgerock.org/en/openidm/2.0.3/integrators-guide/index.html#appendix-rest

OpenDJ:

http://docs.forgerock.org/en/opendj/2.6.0/admin-guide/#chap-rest-operations