Identity & Access Management In The Cloud

Last week I was asked to give a presentation at the IBM Tivoli User Group on Identity & Access Management In The Cloud to IBM employees, IBM Business Partners and customers of IBM Tivoli Security products. I soon realised that my first problem was going to be defining The Cloud. Not everyone I spoke to in advance of the presentation knew what The Cloud was!

So What Is The Cloud?
The Cloud seems to be a term bandied about all too readily these days and for many people it merely represents everything that happens on the Internet. Others, however, are a little more strict with their definition:

"For me, cloud computing is a commercial extension of utility computing that enables scalable, elastic, highly available deployment of software applications while minimizing the level of detailed interaction with the underlying technology stack itself."

"Computing on tap - you get what you want literally from a socket in the wall."

"Cloud computing is just a virtual datacenter."

Wikipedia, naturally, has its own definition.

Cloud computing is Internet based development and use of computer technology. In concept, it is a paradigm shift whereby details are abstracted from the users who no longer need knowledge of, expertise in, or control over the technology infrastructure "in the cloud" that supports them.

Of course, there are different levels of computing that a provider in the Cloud can offer. The usage of a particular software application (eg Google Docs) is just one such offering. Another would be akin to a software development platform (think Google App Engine, Microsoft Azure and Salesforce's force.com). Then, of course, there are the raw infrastructure services - servers provisioned "on-tap" for end-user usage (eg Amazon Ec2).

We are probably all users of Cloud services if we think about it. A quick look inside my Password Safe vault reveals almost 300 different User ID & Password combinations for services on the net including:

• Blogger [blogging platforms]
• Twitter [divulging incoherent thoughts]
• Facebook [staying in touch]
• LinkedIn [professional networking]
• Google Docs [MS Office Alternative]
• Gmail [eMail]
• Screenr [screencasting]
• ChartGo [charting application]

The Enterprise Model
While it is easy to see how personal usage of Cloud applications has grown over recent years, it may come more of a surprise to learn how the Enterprise is adopting Cloud usage.

According to EDL Consulting, 38% of enterprises will be using a SaaS based eMail service by December 2010. Incisive Media report that 12% of Financial Services firms have already adopted SaaS, mainly in the CRM, ERP & HR fields. And our friends at Gartner reckon that one-third of ALL new software will be delivered via the SaaS model by 2010.

My guess? SaaS is already happening in the enterprise. It's here and it's here to stay.

With any change to the enterprise operating model there will be implications - some real and, just as critical, some perceived.

In the Perceived Risks category, I'd place risks such as loss of control; storing business critical data in the Cloud; reliability of the Cloud provider; longevity of the Cloud provider. Of course, these are only perceived risks. Who is to say that storing business critical data in the Cloud is any less risky that storing in the enterprise's own data centre? There may be different attack vectors that need to be mitigated against, but that doesn't mean the data is any less secure, does it? And who says the enterprise has to lose control!

Real risks, however, would include things like the proliferation of employee identities across multiple providers; compliance to company policies; the new attack vectors (already described); privacy management; the legislative impact of data storage locations; and, of course, user management!

Cloud Standards
As with any new IT delivery methodology, a raft of "standards" seem to appear. This is great as long as there is wide-spread adoption of the standards and the big suppliers can settle on a specific standard. Thanks goodness for:

• The Open Cloud Manifesto (http://www.opencloudmanifesto.org/)
• The Cloud Security Alliance (http://www.cloudsecurityalliance.org/)

These guys, at least, are attempting to address the standards issue and I am particularly pleased to see CSA's Domain 13 on Identity & Access Management insisting on the use of SAML, WS-Federation and Liberty ID-FF.

Access Control
And on that point, the various Cloud providers should be congratulated on their adoption of security federation. Security Assertion Markup Language (SAML) has been around for over 6 years now and is an excellent way of providing a Single Sign On solution across the enterprise firewall. OpenID, according to Kim Cameron, is now supported by 50,000 sites and 500 million people have an OpenID (even if the majority don't realise it!)

The problem, historically, has been the problem of identity ownership. All major providers want to be the Identity Provider in the "federation" and Relying Parties were few and far between. Thankfully, there has been a marked shift in this stance over the last 12 months (as Kim Cameron's figures support).

Then there are the "brokers". Those companies designed to make the "federation" process a lot less painful. The idea is that a single-authentication to the broker will allow wider access to the SaaS community, as such:

Symplified (http://www.symplified.com/) and Ping Identity (http://www.pingidentity.com/) seem to be the thought leaders in this space and their marketing blurb comes across as comprehensive and impressive. They certainly tick the boxes marked "Speed To Market" and "Usability" but again those perceived risks may be troublesome for the wary enterprise. The "Keys To The Kingdom" issue rears its ugly head once more!

Identity Management
SPML is to identity management as SAML is to access management. Right? Well, almost. Service Provisioning Markup Language (SPML) was first ratified in October 2003 with v2.0 ratified in April 2006. My guess? We need another round of ratification! Let's examine the evidence. Who is currently using it? A Google search returns precious little. Google Apps uses proprietary APIs. Salesforce uses proprietary APIs. Zoho uses proprietary APIs. What is the point of a standard if nobody uses it?

Compliance & Audit
Apparently, forty times more information will be generated during 2009 than during 2008 AND the "digital universe" will be ten times bigger in 2011 than it was in 2006! Those are staggering figures, aren't they? And the bulk of that data will be quite unstructured - like this blog or my tweets!

The need for auditing the information we put out into the digital universe is greater than ever but there is no standards based approach to Compliance & Audit in the Cloud!

Service Providers are the current custodians of the Compliance & Audit process and will likely continue to do so for the time being. Actually, the Service Providers are quite good at this as they already have to comply with many different regulations across many different legislative jurisdictions. Typically, however, they present Compliance & Audit dashboards tailored to vertical markets only.

It's understandable, I guess, that for a multi-tenancy service there will be complications separating out relevant data for the enterprise compliance check.

Moving To The Cloud
There are providers out there who claim to be capable of providing an Identity Management as a Service (IDaaS) which sounds great, doesn't it? Take away all that pain of delivering an enterprise robust IdM solution? In practice, however, it works well for enterprises who operate purely in the Cloud. These solutions already understand the provisioning requirements of the big SaaS operators. What they can't do quite as well, though, is the provisioning back into our enterprise systems! It's not enough to assume that an enterprise runs everything from their Active Directory instance, after all. Also, we have to remember that using an IDaaS is akin to giving away the "Keys To The Kingdom". Remember our perceived risks?

An alternative is to move the enterprise IdM solution into the Cloud. Existing installations of IBM Tivoli Identity Manager or Sun Identity Manager or {insert your favourite vendor here} Identity Manager could be moved to the cloud using the IaaS model - Amazon EC2. The investment in existing solutions would be retained with the added benefit of scalability, flexibility and cost-reduction. Is this a model that can be adopted easily? Most certainly, as long as the enterprise in question can get its head around the notion of moving the "Keys To The Kingdom" beyond its firewall.

Conclusion
The next generation of user is already web-aware - SaaS is here to stay - and SSO is finally within our grasp with only a handful of big players dragging their heels when it comes to implementing standards such as SAML v2.0. It was also intriguing to play with Chrome OS last week (albeit an early prototype version). Integrating desktop sign on with the web just tightens things that bit further (in a Google way, of course).

Provisioning (whether it is Just-In-Time or Pre-Populated) is still the pain-point. Nobody seems to be using SPML and proprietary APIs abound. Nailing this is going to be critical for mass adoption of SaaS solutions.

While Provisioning is the current pain-point, however, Governance, Risk & Compliance will be the next big-ticket agenda item. The lack of standards and proliferation of point solutions will surely start to hurt. Here, though, I run out of ideas.... for now. Seems to me that there is an opportunity for a thought leader in this space!

Learning Authentication

Securing mission critical applications is vitally important. Everyone can agree on that. Securing access to personal information is also vitally important. I'm sure there'll be no arguments with that one either. And I'm also quite sure that there will be no arguing with the fact that not all applications carry the same risk and therefore they can be secured in various manners ranging from pretty insecure to secure to the point where even with all the necessary credentials it is still hard to get access.

When I was young, I had a ZX Spectrum 48Kb. When I switched it on (because in those days I had no concept of “booting”), I was presented with a fairly blank screen and a cursor. At this point, I would normally type LOAD “” and insert a cassette into my attached cassette player. A program would load (normally a game to be fair) and I would enjoy the pleasure of using the program (or playing the game) for quite some time thereafter. No authentication necessary.

These days, our children need to be a lot more careful as they typical use computers in a state of always being connected to the internet. But is it reasonable to expect a young child to enter a User ID and Password when they want to play “Dora The Explorer” on the Cbeebies website? Maybe they should have to authenticate at an early age – after all, it is teaching them good practice, yes?

Well, there's probably no harm in having a child click on a photograph of themselves when it comes to authenticating at the OS level and then getting access to a customised desktop with all their favourite links on it (such as the now infamous Dora) but what about a password?

Would it be fair to ask a child of 10 to construct an eight character password which had to have alphabetic, numeric and symbols in it? They might be able to do that and remember the password. What about a child of 6? What about a child with learning difficulties? I would suggest that a hard to remember password would be inappropriate – especially if all they were trying to access is the aforementioned Dora in her quest to defeat the naughty Sniper!

So what would be an appropriate means for this demographic to learn the beauty of authenticating themselves? Retina recognition? Finger-prints? Visual cues? Let's examine...

Bio-metrics may seem like a fun way of authenticating and it certainly has merit except that not every PC or laptop comes equipped with the necessary hardware to enable it. Should we all rush out and buy finger print readers? I'm thinking not.

Passwords aren't necessarily an option even if we make the passwords very weak indeed. Maybe the children aren't at a stage in their development where they can recognise the characters on the keyboard let alone use the keyboard appropriately.

Visual cues? Consider the scenario whereby the child in question clicks on their own photograph to authenticate and is then presented with four images of animals from which they have to select their favourite. Now, consider the scenario whereby the child is presented with four colours from which they have to select their favourite. All of a sudden, we are actually verifying that there is a good chance that the child is who they say they are. The child is learning the beauty of IT security in a safe environment with visual cues which are protecting non-critical services. The authentication process is probably one of the least secure mechanisms I can think short of no authentication whatsoever. However, in an environment where security doesn't matter and for the benefit of educating the young and getting them used to the concepts of identifying themselves and verifying that they are who they say they are, then it probably has merit. (And no doubt has already been done many times before.)

I spend my life working with IBM Tivoli security products, focussing on Tivoli Access Manager and Tivoli Identity Manager. I haven't come across an EAI for such an authentication mechanism but would imagine it would be easy to implement and could be very useful within learning environments. Maybe I'll write one in my spare time!

So is there a drawback? Of course there is. And it is the same drawback that exists for all user credentials. Setup, user registration or the provisioning process. That issues seems (to me, at least) to rest with the educators who can talk the child through the process and explain the reasons behind it.

SSO Still Hard After All These Years

Web Single Sign On isn't a new technology - it has been around for many years. You would think that the technology community would have this particular challenge "in the bag" yet the evidence of a frustrating day at work today would suggest that this may not be the case.

Authenticating once and accessing multiple web based applications without further authentication challenges is something that most people should be used to be now. Authenticating to Google allows you to access their Mail, Calendar, Docs and Blogger applications without the annoyance of constantly inputting your User ID and Password, right? Similarly, the big boys of the services world have provided us with Siteminder, Tivoli Access Manager for e-Business, Sun Access Manager and various others. In short - techies know what they are doing when it comes to minimising authentication challenges.

WRONG!

It seems that web based applications are still being developed in a manner which overly complicates the SSO capability. Worse still, this is not limited to the part-time developer knocking out PHP based apps in his spare time. The big services companies are not blameless here!

Today, I had to provide a mechanism whereby users could authenticate using a WebSEAL instance (part of the Tivoli Access Manager for e-Business suite) and then SSO their way to the Microsoft Live service for access to Mail and Calendar applications.

An IBM product fronting a Microsoft product? Two big companies committed to the notion of SSO and federation?

Microsoft make the Windows LiveID SSO Kit documentation available online which is great, but the SSO Kit itself is only available upon request via the Microsoft Connect website. That was a bad start but was resolved soon enough by pulling some strings. The documentation details three integration scenarios, two of which assume that the authentication provider will be an IIS based application. As you will have guessed from the requirement (above), IIS plays no part in the solution which leaves us with the third scenario.

The third scenario requires the authentication provider to make a SOAP call to the Windows Live Service in order to retrieve a Short Lived Token which is then passed to the Windows Live Login service.

No big deal, right?

WRONG!

Where is the SOAP service hosted? Where is the WSDL? What parameteres are passed to the SOAP service? These things aren't documented! It's as if Microsoft have assumed that nobody in their right mind would try to do this and the IIS scenarios are the way to go!

The real answer to these questions, of course, is that the information is available - if you are prepared to hunt for it. Hidden in the document is a sentence which states that the implementer should refer to the partner4.xml document for the SOAP service URL. And partner4.xml is where? Well, it's not in the kit! Again, you have to go hunting online for it (and it isn't called partner4.xml either).

To be fair, the documentation to say that if you want to adopt this scenario, you should deconstruct the C# source files provided for the IIS scenarios and write your own routines. The C# source files have limited comments (as you would expect) and there are a number of them. Trawling through source code is now required (and I'm not a C# expert).

While I'm sure that this will eventually work, it seems to me to be too difficult to even gather the information required for the build never mind performing the build. The information is available, but it is certainly not intuitive. So today was an expensive day spent hunting for information and very little progress was made. Maybe tomorrow will be more productive!

For info, the following C# source files are the interesting ones:

• LIVE_SLT.cs
• CredentialServiceAPISOAPServer.cs

Federation v ESSO

It's well understood that achieving single-sign on in the enterprise is an admirable target. The complexities of rolling out such an infrastructure may mean that integrating all enterprise applications with a common security infrastructure will take some time (if it is even possible).

But what happens when single-sign on to a third party is a target?

Readers will already be aware that I am a fan of the concept of security federation but how many organisations have federation-aware applications? Over the last 2 years I have been met with a consistent answer to this question when broaching the subject of federation with third-parties. None!

Maybe we have just been unlucky with the third-parties we have been dealing with but I suspect the real answer to the question is still pretty close to "none".

So, do we force these third-parties to migrate to a federated security approach or do we just accept that our employees will have to have a separate UserId/Password for the third-party site/application? Or is there another way?

Well, I'm quite sure with just a little bit of effort we could provide a mechanism to automate the sign-on process on behalf of the employee. I'm quite sure that with a bit more effort, we could automate the process of changing passwords upon password expiry. I'm also reasonably confident that with (considerably) more effort, we could automate the provisioning process. And everyone is happy once more... until the third-party changes the various screens used for each of these functions.

You see, it would seem that most of these third-parties haven't even exposed an API catering for these functions.

However, the idea of scripting the logon process seems like a reasonable stop-gap until full federation is achievable and this is the focus of applications like Passlogix's V-GO suite (available at http://www.passlogix.com/). Indeed, this little application seems to tick so many boxes that the guys at Passlogix have struck deals to allow some of the big boys in enterprise computing to sell the software in rebranded form: IBM Tivoli and Oracle to name just two.

Are there any downsides?

• It is a client application that needs to be deployed onto the desktops/laptops within the organisation
• It is a Windows only application
• It doesn't seem to support Firefox

The upsides, of course, are that is should be a relatively quick and easy approach to achieving SSO with a third-party. I can't help thinking that an amalgamation of Password Safe and Auto-It could achieve the same thing.

• http://passwordsafe.sourceforge.net/
• http://www.hiddensoft.com/autoit3/

So, do I feel compelled to develop a freeware alternative to Passlogix's offering? No, I'm afraid not despite the fact it would be an interesting exercise. The additional features of V-GO would sway me towards buying the off-the-shelf package (although I have no idea how much it costs!)

And what about our federated security solution? Unfortunately, we are faced with a tricky situation. This type of solution requires both parties within the federation to have security federation aware systems. Deploying such systems is a "leap of faith" - faith that others will follow suit. Within my experience, none of our third-parties are ready to take that leap... yet!

Time for Fun!

It's the last working day before Christmas and therefore the time to ensure that everything is in order for the holiday period.

More importantly, it's time for some "resting" and fun.

My friends and I had great fun this morning discussing the results of the Hobbit Name Generator which can be found at http://www.chriswetherell.com/hobbit/ - it is well worth a 5 minute visit.

My Hobbit name is "Mungo Loamsdown of Deephallow" with which I'm quite pleased. We were also particularly impressed with "Minto Hamwich of Buckleberry Fern".

We all have a name yet we are known by various names & identities depending on who is addressing us. I respond to the following:

• Stephen (and sometimes Steve)
• Sir
• Son
• Daddy
• Mr. Swann
• Oi You
• (and now Mungo Loamsdown)

Nothing particularly unique in much of that unfortunately. When it comes to accessing systems (whether they be web based or not), the combination of identities that I have is even greater. I like to think I know who I am but it is a sorry state of affairs when you not only have to commit your passwords to some medium other than your brain, but you also have to have a serious think about recording (and transporting) your "name" in a similar manner.

• At my bank, I am a number.
• On my blog, I am an email address.
• At work, I am a combination of letters and numerals.
• On my web based training site, I am a nickname.

Will there ever be a time when I can be considered truly unique and known by all as a single name?

Nah... I'll always be either a son, daddy or husband. But there must be a chance that the number of identities I own can be reduced significantly. The utopian world which includes an Identity Provider as a service which can be utilised by all these various systems sounds great (if a little dangerous if it were ever compromised). The world of security federation is just around the corner and I for one can't wait - my brain is stuffed to capacity with UserIDs and Passwords!

In the meantime, I might just change all my UserIDs to "Mungo Loamsdown" :-)

Merry Christmas everyone...