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.

Getting back into the swing of it

It’s been a while since my last blog entry so I thought I'd post get back into the swing of things with a posting on the topics that have been occupying me over the last few months.

• Federated Single Sign On - with and without TFIM

Over the last 6 to 9 months I've been getting more involved with Federation, specifically within the context of Identity Management and Single Sign On. I've been interested in this area for some time now, mostly because of the Identity Management challenges it can solve, as well as its ability to knit together applications that have a requirement to interoperate regardless of their geographic or DNS location.
Since gaining my 'IBM Tivoli Federated Identity Manager v6.1 deployment professional' certification in June'10 I've tried to increase the breadth of my understanding in this area and learn about the other complementary technologies and standards. This has given me the opportunity to study XACML (externalised application authorisation processing), OAUTH, Federated Provisioning and Cloud application integration (e.g. GoogleApps, Force.com, Zoho). The culmination of all this study generated a wish to create my own Federated Identity Provider, which would be a great development and learning tool. To build this Identity Provider I chose to use the OpenSAML framework.

This is one area about which I will be adding blog entries in the coming weeks as the SAML standard alone is quite rich and I've already learnt a great deal. Hopefully this will all be of interest to anyone getting into the area of Federation and/or the OpenSAML framework.

• Setting up custom ITIM workflows and ITDI adapters

As part of my role as a security consultant for Pirean, I am currently working on a very large identity management deployment, which involves ITIM. As you'd expect, a single product can never cater for every requirement, so where there have been gaps in the product I have needed to design and build several customised components. Where I can, I'll be posting any useful details on these, including those that I've already built.

• Setting up a network based music system at home and adopting HD audio

A couple of years ago I invested in a Network Attached Storage drive (a Netgear ReadyNAS Duo if you're curious), which I used to store all my photos (i.e. wedding) documents and music files. After a while I pulled out the default western digital 500 GB disk and replaced it with a pair of 1.5TB Samsung F2 eco drives, which the NAS allowed me to setup as a mirrored pair. The result of all this was that I now had around 1.4TB of disk space that would survive any single disk failure. With this in hand I took on the task of centralising and (yawn) cataloguing my entire music collection. This led me to question:

1. how could listen to my music in the easiest and most portable manner that allowed me to avoid having to turn on my 'generic mp3 music player'
2. Was I getting the best audio quality from my music collection

Again in the coming weeks I hope to add some posts on the setup I've created at home and also try and give some useful pointers to help out anyone who may be thinking of doing something similar in future

• DLNA and 3D TV

Finally, in a similar vein to the previous point, I've been interested for some time about if and how it could be possible to digitise, and therefore remove the need for, any physical media in one's life i.e. no more CDs, DVDs, Blu-Rays or Vinyl. Using my NAS drive, a PS3 and a Samsung LED TV I've created what I think it quite a nifty system that attempts to realise the aspirations of the Digital Lifestyle Network Alliance (DLNA). As an extension to this I've recently taken ownership of a Samsung LED 3D TV (ue40c8000 for those that are curious) which I'm only now getting used to. As before, I intend to add posts around the DLNA setup I have at home, my experience with 3DTV and any pointers/lessons I've picked up on the way.

Quite a lot there as you can see, which now makes me wonder why I didn't start this earlier?
Now..... where to start?