« Oracle and IBM databases: Disk-based vs In-memory | Main | When to migrate your database? »

February 02, 2010

Scale out your identity management

BigDataMatters is focused on the issues faced when processing and managing large amounts of data. In light of this, it would be a crime not to blog about the security of this data. Over the next few weeks, I will write a series of posts focused on Identity management in the enterprise. Before you read any more, how is your identity secured?

Does your working day start with logging into your workstation? Then your email with another user ID and password, and then another application, another .... Isn't there a better way? Yes, single sign-on (SSO). So why are some enterprises still using a single account per service model?

The main reason is simplicity and a lack of forward thinking. If a new service is to be introduced quickly, it is easier to implement it out of the box using this model. The downsides are 1) users suffer from password overload and end up scrawling access details on bits of paper for all to see 2) administrators don't have a single point of management and end up creating custom scripts to manage user access for each service. A strength of this model is that each service works independently and if one goes down, the others remain operational. However, if you have this kind of security model then you shouldn't say it loudly. I suggest you ask your IT “why?”.

The first step to SSO can be made using a centralized account model - you access company services using a single account. In small enterprises it is the recommended model as it is simple to set-up and the centralization of accounts streamlines administration. But, with this simplicity comes a catch - a single point of security failure. If the authorization system fails or is compromised, no user can access their services. Work comes to a grinding halt! Fault tolerance and high security is a must in such systems. Such architectures can be easily created using LDAP, Kerberos or Active Directory.

Greater SSO functionality is provided by a decentralised account model - not only can you access services in your own enterprise using a single account, but also those in other enterprises. This allows Doctors who often work in multiple hospitals to simply, securely and rapidly access patient information. The underlying concept of this model is a trust relationship. Much like the passport system - one country issues it and all others trust it.

Implementing a decentralized account model is non-trivial and requires careful planning. Existing services need to be incrementally integrated to allow glitches to be fixed without bringing down your existing identity access management. This architecture can be achieved using technologies such as Oracle Identity Managment, OpenSSOShibbolethADFS or Kerberos. 

I have provided a quick overview of how to implement SSO, but is it more secure? The simple answer is yes. You only authenticate once, using either your password, certificate, smartcard or even biometric methods (voice recognition, iris recognition etc.). After authentication, you get a token which you use to access other services. For security, this token is usually time limited meaning that you can only use services for a period of time. It is the most secure system, because only you and the authorization server know your password.

To follow ...

For the next post, I want to share my experience of implementing decentralized SSO with Kerberos. Let me know if you want me to address any topics or questions?
Bookmark and Share


TrackBack URL for this entry:

Listed below are links to weblogs that reference Scale out your identity management:


Feed You can follow this conversation by subscribing to the comment feed for this post.

The first step to SSO can be made using a centralized account model - you access company services using a single account. Yeah, you blog structure is so simple, I like the style. I also like writing something if my spare time. So I can learn something from your article. Thanks.

This is very good sharing .But here is a problem.I see lots of reference to SSO tools and methods, but I'm not seeing your concept of Scale Out IDM.

The comments to this entry are closed.