Blog

Identity Management Solutions 101: Enterprise Single Sign-On

So, you're an IT Manager and need the low down on a new buzzword in the realm of Identity Management, and you need it quick...You've come to the right place! This series is designed especially for you.

This entry is about Enterprise Single Sign-On. Enjoy!

If you need more details on this and other disciplines in the world of Identity Management, or you'd like to get some other folks from your staff to join in on the fun, you might be interested in an on-site Identity Management Workshop.

Alias	ESSO, Enterprise SSO, SSO
Function	To provide single sign-on capabilities to the entire organization for all types of applications, including client server apps and applications accessed over terminal emulator.
Misc. Facts	Healthcare institutions love ESSO, usually because physicians can't stand logging into 20 different applications every day. Implementation cycles are relatively short, and can usually roll out the solutoin and integrate 3-5 applications in under a month. Biometrics and other 2-Factor Authentication forms are popular integration points, and can compensate for security concerns associated with SSO.
Business Benefits	Happy users! Users sign on to the network in the morning, and never again (until the next morning). Believe it or not, some companies have performed analyses on how much time is wasted for end users logging in and out of applications throughout a day, in order to perform an ROI analysis for implementing this technology. Run the numbers, it may surprise you! Reduction in Password Reset calls to helpdesk
Use Case	An end-user logs onto the network in the morning, clicks on an app, and gets automagically signed in! Clicks another app, the same. A user signs onto application, which prompts the end user to change their password since 90 days passed. The ESSO solution automates the password reset to a randomly generated password. The user never needs to know it since they are automatically signed in using the ESSO solution!
High Level Architecture	Each workstation has a client loaded on it that learns the sign-on behavior to various application the first time a user authenticates to it. The authentication profile along with the credentials are then stored in a backend data store. The next time the user attempts to log on to an application, the ESSO agent recognizes the sign-on screen and populates the credentials and automates the sign-on process.  Some architectures utilize an additional piece of middleware and store credential sets there, while others use a directory (AD, for example) to store all of their data.
Caveats	Each workstation requires an agent to be loaded on it for this solution to work, which could pose some challenges for access from non-managed machines. Solutions that do not use a "middleware" piece might require schema modifications to your active directory environment.

Identity Management Workshop: Critical Ingredients

An Identity Management Workshop can be a fantastic way to start an IdM Project - if it has all the right ingredients.  Unfortunately, with the wrong ingredients an Identity Management Workshop could erode the valuable goodwill of the participants, making the critical starting phase of your Identity Management project all the more difficult.

We've compiled a checklist of some of the right ingredients for a successful Identity Management Workshop. Enjoy!

Give Yourself Some Prep Time 

Prep time means gathering some information about your Identity Management initiative such as business drivers, technical drivers, high level business processes, budget parameters, current technology infrastructure, resource limitations, etc. If you get your hands on a Pre-Workshop Questionnaire, spending time with your team filling it out should help unearth some valuable information and help you set your parameters.  

Heaps of Stakeholder Participation 

A workshop should not be an IT-only initiative (since IT-only Identity Management initiatives tend to fail). The appropriate representation from various departments and business segments of your organization will ensure that the discussions will be balanced and couched in terms of real-life business processes.  Do your level best identifying the stakeholders that should be present, and who in your organization best fits those roles. 

A Pinch of Skepticism and a Bunch of Conversation

Too much skepticism can be a barrier to communication, but just a pinch might enhance the conversations during the Workshop.  A few things to be skeptical about:

• A one-size-fits-all solution
• A 6 month roadmap
• A lecture (the value of the workshop is the conversation it initiates)
• Someone trying to sell you something. (This should be about your organization, not an "offering"!)

Mix in Some Business Processes Analysis

At the heart of an Identity Management project is enhancing identity-related business processes. The absolute wrong way to begin analysis of your environment is to start talking about data synchronization and go up. Start by analyzing the relevant business processes, then analyze how they impact the systems/applications in your environment, and finally analyze how those interactions impact the underlying data.

But Hold the Software Vendors

A workshop led by an Identity Management software vendor will most likely lead to skewing your requirements to match the vendor's capabilities.  It would be more appropriate to use a neutral third party Identity Management Consulting firm that can help you unearth and refine your requirements first, and then provide you the relevant information regarding vendor capabilities to help you make an informed decision.

So there you have it. I'm sure we missed something, so feel free to add in the comments section!

How to Make a Better Identity Management POC

Mike Trachta opined about lackluster POCs by highlighting the difficulty posed to SIs to live up to the fantastic show presented by the POC folks.

"...the customer remembers more about the POC than you think. They remember how pretty the screens were. They remember how seamlessly all the pieces fit together, and how quickly each task executes. What they don't realize is that all of the data is massaged and simplified. Of course the POC could do these things! It has 3 users with 4 roles to choose from, and doesn't include any of the "exceptions" often found in the customer's environment. When it comes time to actually implement this feature with 30,000 users things can (and do) get quite a bit more complex."

Jeff Bohren put together an eloquent post as well, pointing to his experience as the developer in the background helping out both the POC folk, as well as the SI who has to make this happen for real. It's a great read and provides insight from both ends of the spectrum.

Here are a few suggestions that might make your IdM POCs a little better. So here they are:

1. Couch your immediate goals in the context of a larger Identity Management roadmap that ties it to your business objectives. Jeff already hit on this point in his post, "Instead of doing a POC of who has 'The Most Magical Bullet', enterprise would be better suited to craft a long term IdM strategy and chose a vendor whose product best aligns with it." This approach voids the notion that phase 1 of the project has to cover everything under the sun. A fantastic way to do this is to engage an SI that understands the game, and can walk you through an Identity Management workshop that speaks to both your business and technical objectives.

2. From your workshop findings, carve out a Phase 1 of the project that is attainable - the best way to do that is to write up a handful of detailed use cases that boils the expected deliverables down to non-technical language.

3. Highlight the top X number of use cases to focus on for a POC. Keep it limited (but representative) of your expected project deliverables. Identify the vendors who might be able to respond, and request a technical architecture document outlining their approach to solving the use cases you have identified and have a Q&A session with them. Filter out the vendors who don't make the cut (yes, I know that's a loaded sentence), and identify the top 1 or 2.

4. Prepare a POC lab. (Another loaded sentence).

5. Bring the vendors in, but don't allow them to touch anything! OK, this suggestion point might be a bit much but I suggest that, as much as possible, have the vendor's experts sit on their hands, next to your techies while your techies drive. If the vendor whips out a canned script, your guys will know it (and document it in the findings). If the vendor has to make a nasty directory schema change, your techies will know it. If the vendor has an ugly hack that inserts pages of code into the presentation layer of the "ultra configurable identity app", your techies will know it.

6. Have a structured way to present the findings.

While I know that the approach above requires a lot of background knowledge and support, it just seems to be a much more valuable experience that actually tells you something that a demo can't. If help is needed, supplement the team with an IdM Consulting firm that has strong experience in the space. Either that, or save everyone time and effort and just make your decision based on sales demos and references.