Adapting to a changing IT landscape through the adoption of Cloud technologies

Recent significant advances in virtualization technology have allowed organizations to make enormous efficiency, resource and cost savings, as well as reduce their carbon footprint. This coupled with an explosion in outsourced IT processes through the usage industry strength Cloud based SaaS offerings have contributed to a significant change in the IT service management and hosting landscape. An increasingly global distributed user base coupled with social media offerings such as Twitter and Facebook have contributed to a change in the online user experience so that users now increasingly expect disparate services to be seamlessly 'joined-up' and personalized. At the same time the source and variety of security risks has increased exponentially due to the continued uptake of online services by the public and changes in the way these users consume online services. All these changes place massive demands on legacy IT infrastructures, as the days when the data center was king are now gone. Organizations will continue to struggle to meet these challenges without significant disruption and process reengineering. Coupled with the inability to rip up and replace legacy systems, the only recourse is to extend existing infrastructure in a secure and standards-based manner.

Achieving greater IT service flexibility and functionality whilst preserving existing investments and processes is obviously a non-trivial task. Coupled with the need to ensure that any (re)engineered services are still governed by an organizations' existing set of security controls and policies, requires a very different set of IT solutions. By extending, enriching and securing disparate systems in a standardized manner using Cloud technologies such as SAML, OAuth and XACML organizations can maximize their existing IT investments and gain increased service agility.

Security Assertion Markup Language (SAML) is a standard that allows a user population to securely access resources regardless of their location and HTTP domain. In 2005 SAML v2.0 became an OASIS standard, which is the convergence of SAML v1.x and Identity Federation Framework (ID-FF) v1.2. Since that time SAML has become the default protocol for Federated Identity Management (FIM) solutions and giving rise to other FIM related standards. Through the exchange of SAML tokens between Identity Providers (IdP) and Service Providers (SP) entities, users can seamlessly move between different parties within a Federation in a secure manner supported at all times by a predefined 'Circle of Trust'. Within the context of a business and its employees, SAML can be used to facilitate Single Sign On between a set of divorced systems, such as two Access Management vendor products within a single organization, or an existing in-house Access Management solution and a Cloud based SaaS offering. In this context it can be seen that the usage of SAML tokens would allow an organization to preserve their existing Identity and Access Management processes and extend these to encapsulate an outsourced service based in the Cloud.

Open Authorization (OAuth) is a standard that is used to increase data portability by facilitating the distribution of private user data between disparate IT systems through the exchange of tokens and not credentials. Published in April 2010 as the document RFC5849 and currently at v1.0a (with v2.0 in draft), OAuth is gaining increased popularity - most notably in 2010 when Twitter adopted it as its default mechanism for integrating with 3rd party applications. Although SAML tokens can be used to exchange user information (as 'attributes' or 'claims') in a trusted manner, the key advantage of OAuth is that it places consent in the hands of the user about whom the data describes. For organizations that store and use sensitive user data as part of an existing business service, OAuth can be used to easily and securely allow other consumer IT systems to request and reuse this user data in a user consent driven manner without the need for expensive application interface development. By increasing the distribution of user data between its IT systems, an organization could increase the richness and personalization of its user-centric systems whilst mitigating or reducing enterprise application integration costs.

Authorization policy management across an entire IT estate is traditionally a very resource intensive task as any change to a policy requires the modification (and testing) of a entire suite of applications. Externalizing authorization policy definition and decision making to an external entity, through the usage of eXternalised Access Control Markup Language (XACML) definitions can significantly increase the flexibility of an application portfolio, and also reduce the cost and effort required to make any future change. Originally published in 2001 and currently at v2.0, XACML support can be increasingly found in vendor product portfolios such as IBM's Tivoli Security Policy Manager (TSPM), ForgeRock's OpenFM and Axiomatics' Policy Server. Version 3.0 is currently in draft and will add critical new features such as Multiple Decision Profile, delegated administration and Obligation statements. In a business environment XACML definitions can be used to centrally define the policy governing what user entitlements are required to access a particular resource, thereby providing a single and auditable view of the security risk across the entire estate. If a new application resource is deployed or a new security risk is identified, the usage of a separate Policy Definition Point (PDP) an organization would simply be required to make the necessary XACML policy definition changes with immediate effect.

In summary, significant advances in Virtualization, the rise of Cloud services and the raft of new Federated Identity Management related standards have together had an enormous impact on the IT industry. These advances have given rise to a multitude of new opportunities such as Green IT through data center consolidation, smarter and richer IT services through increased user data portability and finally increased business agility through the federation of disparate services. Organizations that do not or cannot adopt standards such as SAML, OAuth and XACML will continue to experience great difficulty when attempting to adapt to their legacy systems to an ever changing IT service landscape.

Adding a slice of reality to user entitlement policy definitions

Role Based Access Control (RBAC) as a means of defining user entitlements is as ubiquitous across the Identity Management industry as Facebook is to the 21st generation - there were several key players before it and it isn't always the best tool for the job, but it sure is popular.

Since its very inception and initial rollout, RBAC has forced the implementer to carryout some quite intensive business analysis tasks, which to name a few include:

• The need for (sometimes massive amounts of) role 'mining' to understand what business functions currently exist and how these map to a set of logical roles.
  
• Mapping logical roles to user entitlements within target business applications
  
• In very large deployments, the need to create role hierarchies to rationalise the overall number of roles

Instead of simply documenting the existing processes and entitlement sets, RBAC requires an organisation to interpret the discovered information in an RBAC manner. Anyone who has ever attempted to learn a foreign language will know that translating a concept back into your mother tongue before attempting to understand it is always fraught with difficulty and can be subject to misinterpretation. Instead a more reliable approach is to capture and understand the subtleties of a concept in its original form.

Capturing common user entitlements and exceptions is obviously an extremely useful business analysis task, which is required during any Identity Management implementation. A risk that must be mitigated through such an activity is the loss of user entitlement fidelity. By trying to force 'square pegs into round holes' organisations can actually find that their resultant Identity Management solution is costly to build, difficult to maintain, and inflexible. Primarily this is because the real user entitlements on the ground must be (re)mapped to a set of roles during the initial deployment and regularly throughout entire lifecycle of the Identity Management solution. This is a key point that Attribute Based Access Control (ABAC) is able to alleviate through the implementation of standards such as XACML. For those with even a basic RBAC/ABAC knowledge this view is nothing new, however I think that its worth outlining a real-world use case that conclusions that are being made on the ground to back this up.

Before I jump in with the real world examples, it might be useful to briefly cover XACML and how it relates to user entitlement definition. Oasis (who published the XACML specification originally in 2003) provide the following useful description "XACML is a general-purpose access control policy language. This means that it provides a syntax (defined in XML) for managing access to resources".

Through XACML definitions, an organisation are able to model user entitlements in the form of roles (to preserve legacy implementations) and/or as direct application-specific attributes. Such functionality within XACML may finally allow organisations and implementers of IdM to break away from an entitlement interpretation stance and start defining user entitlements with never before seen expressivity.

Returning to RBAC, a business requirement that I am currently working on with a customer quite plainly shows the significant limitations of RBAC, as opposed to ABAC, in an easy to appreciate manner. The implementation is specifically tasked with the definition of Separation of Duties (SoD) policy. Tivoli Identity Manager (TIM), and many of its peers, implement SoD policy using roles, allowing the IdM administrator to define which role combinations are invalid in their organisation. The prerequisite of this task is clearly that an organisation must have already distilled the existing user entitlements found across the business into a set of roles. To attain the level of role granularity required to implement even a simple set of SoD rules for a small set of business applications (COTS and infrastructure such as Active Directory) requires the definition and management of a massive number of subtly different roles. Such an implementation within even a small to medium sized business can led to so called 'Role Explosion'.

TIM tries to address this deficiency through the usage of role hierarchies. The approach of chaining together roles, thereby reducing their overall number does not increase an organisation's ability to freely express its user entitlements. Instead it could be argued that this approach swaps the problem of role explosion for another - increased role complexity.

A better approach would be to give an organisation the ability to define SoD policies on the actual account entitlements that are under scrutiny, instead of a set of logical interpretations that do not actually exist anywhere. At Pirean we have worked hard to alleviate this problem for TIM customers by supplementing the existing product with our own Pirean Risk Manager (PRM) solution. PRM which is directly integrated into TIM and appears as an onscreen menu item, allows IdM administrators to express SoD rules in terms of business application attributes, thereby moving away from an RBAC centric approach and more towards ABAC. Of course if an application under SoD policy itself uses RBAC then this can also be supported as the role (or group) attribute within a business application will be viewed as just another user attribute.

Within the IBM portfolio ABAC is appearing in products such as IBM Tivoli Security Policy Management (ITSPM). This product is currently more focused towards the real-time processing of authorization requests from an access management entity (or Policy Enforcement Point in XACML terminology).

To wrap up, whilst the the main Identity Management vendors already have ABAC compatible products in their portfolios I believe that over time begin these will be brought directly into their Identity Management and Compliance offerings. This will result in the products taking a more ABAC-based approach as their customers look to express their user entitlements with greater clarity and increase the flexibility of their Identity Management processes.