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.

Notes on building a Federated Identity Provider - Decoding SAML messages

To follow on from my last posting, I have been busy recently trying to build my own Federated Identity Provider, mostly to cement my overall understanding of Federated Identity Management at an architectural and technical level. Just this week I managed to get Federated SSO to GoogleApps working with just a handful of Java components and JSP pages!

For those who are new the area, there are several open source frameworks available to the developer who is looking to deploy their own Identity Provider (IdP) or Service Provider (SP), such as OpenSAML, Shibboleth (built on top of OpenSAML), Simplesamlphp and Lasso. At this point a couple of definitions would probably be useful.
OASIS provides the following definitions:

• Identity Provider: A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation
• Service Provider: A role donned by a system entity where the system entity provides services to principals or other system entities.

Although OpenSAML is essentially a set of SAML libraries and therefore does 'not provide a complete SAML identity or service provider' in the words of its creators, I chose this framework as it provided me with the greatest opportunity to understand the real nuts and bolts that drive Federation. Those looking for an out of the box Federation solution would do better to opt for solutions such as Shibboleth or a vendor product such as Tivoli Federated Identity Manager as these can simply be deployed, configured and run!

Back to OpenSAML, my opinion of it after one week of real hands on use, is that it is quite excellent. Despite the fact that the website is plain and straight talking, its backed up by a great deal of excellent documentation, examples and useful links. If you're like me and you want to start developing a web application using OpenSAML then the section marked 'User's Manual' is for you. The section marked 'Developer's Manual' is for those brave person's who wish to extend the OpenSAML libraries.
After downloading the OpenSAML libraries and importing them into my Java IDE (OpenSAML libraries in C are also available) I started to write a small test app that could decode and unpack an incoming Authentication Request, which would take the form of a XML (SAML) message. SAML messages can be classified as using certain 'bindings', which denotes the method of message transmission. The two most commonly used bindings are HTTP-Post and HTTP-Redirect. For my PoC/test/debug app I wanted to support both bindings, which meant that I needed to be able to accept SAML messages that result from HTTP POST and GET requests. To process messages received from these two channels natively (i.e. without using OpenSAML) is at time non-trivial as URL and Base64 (de/en)coding is required for some bindings, as well as payload (in/de)flation. Using OpenSAML to carryout this task is extremely simple as the two aptly named classes HTTPRedirectDeflateDecoder and HTTPPostDecoder do all the work for you. With a decoded SAML message in hand, and using a couple of supporting utility classes you have access to the unmarshelled SAML message, with all its useful details. The ability to decode, unpack and present an incoming SAML message in itself was (and is) very useful as it provides the ability to compare and contrast SAML tokens generated from different bindings and SPs such as GoogleApps and Force.com. All of this helps to demystify the whole area of SAML message content and communication.

At this point an example would probably come in handy I think. Here's an example of a SAML message that contains a Federated Authentication Request.
Firstly the raw unmarshalled value:

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxzYW1scDpBdXRoblJlcXVlc3Q
geG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCIgSUQ9Im
9pY21hY2VhcG9mZWJwZ29jbG9qbWduZ2RlaGlwa21sb2ZkZmhvZmIiIFZlcnNpb249IjIuMCIgSXN
zdWVJbnN0YW50PSIyMDEwLTExLTAyVDE2OjUzOjA3WiIgUHJvdG9jb2xCaW5kaW5nPSJ1cm46
b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6SFRUUC1QT1NUIiBQcm92aWRlck5h
bWU9Imdvb2dsZS5jb20iIElzUGFzc2l2ZT0iZmFsc2UiIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZV
VSTD0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9hL2NvbXBhbnktZGVtby5jb20vYWNzIj4NCjxzYW
1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0a
W9uIj5nb29nbGUuY29tL2EvY29tcGFueS1kZW1vLmNvbTwvc2FtbDpJc3N1ZXI+DQo8c2FtbHA6T
mFtZUlEUG9saWN5IEFsbG93Q3JlYXRlPSJ0cnVlIiBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpT
QU1MOjEuMTpuYW1laWQtZm9ybWF0OnVuc3BlY2lmaWVkIiAvPg0KPC9zYW1scDpBdXRoblJlcXV
lc3Q+

After passing this value through my decoder app, I received the more readable value of:

<samlp:authnrequest samlp="urn:oasis:names:tc:SAML:2.0:protocol" id="oicmaceapofebpgoclojmgngdehipkmlofdfhofb" version="2.0" issueinstant="2010-11-02T16:53:07Z" protocolbinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" providername="google.com" ispassive="false" assertionconsumerserviceurl="https://www.google.com/a/company-demo.com/acs"><saml:issuer saml="urn:oasis:names:tc:SAML:2.0:assertion">google.com/a/company-demo.com</saml:Issuer><samlp:nameidpolicy allowcreate="true" format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"></samlp:AuthnRequest>

Looking at this example message from Google and using even a basic level of SAML knowledge, we can observe several key points regarding their Federated Identity Management solution.

• Google does not sign its outbound Authentication Request messages - The fact that these message are not signed means that it would be quite trivial for a malicious 3rd party to impersonate Google when communicating with a SP
  
• Google uses the SAML v2.0 standard and not SAML v1.0 or any of the SAML alternatives such as WS-Federation or those from the Liberty Foundation
• The naming format used by Google is unspecified (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified).
  
• Google's provider name is 'google.com'
• The Google component that is used to consume SAML messages is Google domain specific, and of the format 'https://www.google.com/a//acs'

All of this information is essential when starting the process of generating a SAML response message. The above details can be picked out of the decoded and unpack SAML message using OpenSAML classes such as AuthnRequest, which provides the methods 'isSigned()', 'getAssertionConsumerServiceURL()' and 'getProviderName()', amongst many others.

At this point within my development process and within my app I had a process that could fully interpret and understand an inbound SAML authentication request from Google. The next task was to use this information, and that specified on the Google site to generate a SAML response message that could not only be understood by Google, but also used to carryout Federated SSO for my target user.
All of this and more will be picked up in my next posting on this topic.
Bye for now.