Worst practices: Exposing IAM blunders

Joel Dubin exposes the most common IAM blunders, and enlightens information security professionals on how to prevent these mistakes. OK, its a bit basic, but they are still problems. I thought the article was uninteresting, but two things caught my attention:

1) multiple logins for multiple applications (listed as the sticky note syndrom)

2) "ghost" passwords - which are more precisely "ghost" accounts, not just passwords, they are logins that should not exist.

If you are correlating any and all identity profiles in your enterprise, then these orphaned accounts can be properly detected AND accounts could be linked to aggregate same-user profiles from the various applications, enabling true SSO. No more multiple logins, no more "ghost" or rogue accounts. 

Utilize an abstraction layer to virtualize sources together, correlate identities, and provide provisioning for identity lifecycle management. Delivering identity data from a central virtualized source can solve this problem.  If your environment is a dynamic and ever changing business (and who's isn't these days) then this is the only way to go. 

read more | digg story

Single Sign-On

There was an SSO webinar today by Quest Software.  I would like to thank them for actually putting some content into it and actually explaining what their solutions offer.  I have become a bit weary of webinars so laden with marketing message, you really have no idea what the technology is offering you or if it will fit your infrastructure or not. 

The recording is available here.   My big take-away's had a familiar ring to them, as I have repeated some of these points too many times to count at this point.  Quest has an offering of multiple applications for an SSO package.  Also, check out Mr Shaw's white paper on the subject. 

First SSO means different things to different people; enterprise SSO, Federated SSO, Web SSO, Single Password, Reduced SSO, etc.  But I believe that some things are the same regardless of the "type" of SSO you want to deploy.

Shaw had a nice list of the "perfect world" for SSO:

• Standards based
• A single password or login
• A single directory
• Strong Authentication support / multi-factor authentication
• Support for multiple platforms
• Support for multiple applications
• Support for "thick, thin, and web applications"

This week I have been faced with some of the problems in solving SSO integration problems and how to deliver identity information to enable SSO.  A client had previously deployed a SSO solution for 35+ applications, using only two sources that were disjointed. Now they were faced with integrating another data source that contained intersection of identities. Some users in the new source exist in one of the other two sources - now the entire SSO solution collapses because it was based on the idea that they would never face an overlap of identities within the repositories.  Again, the answer was to deploy a virtual directory server as the abstraction layer to simplify the management of identities in these, now jointed data sources.

The lesson is, yes you can deploy an application without building a unified infrastructure, but you take a big risk.  When new data sources need to be incorporated (including acquired applications with their respective user-base), you can expect problems. 

PLAN AHEAD.. if you don't need to solve this integration problem now, YOU WILL at some point if you expect any level of scalability.  YES, it is possible to have one source for all your users, without replication.  By using the features of a virtual directory server to create a true union of identities (identities are correlated appropriately and duplicates are eliminated) and extend those entries with additional attributes from the needed data sources, you provide an identity infrastructure to provide authentication and authorization services to your SSO application. 

 

Ideas

Some interesting information about using UNIX abilities to achieve extended function from a distributed authentication environment, specifically laptops to cache (memory) login information when disconnected from the network.

http://blogs.techrepublic.com.com/opensource/?p=127

I think the ideas here are more interesting than the implementation suggested. If you can cache the identifiers, why not do that across multiple LDAP stores, (even from multiple security domains, domain controllers, and AD forests) into a single directory. You couldn't disconnect your laptop, but you could achieve reduced or single sign-on, especially for external applications. The identification step (or search) of the LDAP store would be much faster, once you have the DN the credential check would be sent back to the corresponding LDAP store.

If I have confused you, just let me know... I will be happy to fill in more details of where my mind is going on this after reading this article today....