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.

Poorly Run Identity Management POCs

For those unaware, POC is an acronym for "Proof of Concept", and consists of a client requesting a vendor to bring their software in to demonstrate ("prove") that their software can perform in their environment as promised ("concept"). The engagement usually lasts for a few days to a week, and typically the vendor foots the bill (if the potential deal is large enough). Most often, POCs are borne out of a conversation between a client and an Identity Management Consulting firm or industry analyst who completed a 2 hour identity management market briefing, concluding that it would be a good idea for the client to host a POC. A few vendors are selected to strut their identity management software, and after reviewing which vendor did a better job, a winner is hailed and ultimately awarded the contract.
After being involved in one too many POCs, I've come to the following conclusion: IdM POCs are poorly executed. Usually. And here are a few reasons/scenarios that explain why:

1. A typical POC is just a glorified demo. So, wisdom states that if the vendor is integrating their identity management software with your target applications, then it's not just a demo, but undeniable evidence that their software is good for you and your organization. That is both true and false. Just because software can be made to "seem" to work with your apps is not evidence that the integration is robust or production ready. Hacks are very common in POCs, and a lot of what is demo'd at the end of the POC is a lot of smoke and mirrors and doesn't prove that what was completed is production ready, or more importantly, can ever be production ready.

2. The success of the post-POC demo is highly dependent on 2 individuals on the vendor team: the Sales Engineer (the guy who duck-taped together the POC) and the POC-demo-guy. The vendor that has the best duo typically wins the deal, which may not reflect the best software solution for your environment. A good SE can make crappy software work (with his arsenal of scripts and tricks), and a good POC-demo-guy can bedazzle almost any audience. On the other hand, a bad SE can make good software break, and a bad POC-demo-guy can put a lively audience to sleep.

3. A POC is typically technology focused. Most IdM projects are business process centric (or at least they should be). When decisions are made based on the number of out-of-the-box connectors or the long list of supported standards without considering how it all applies to your specific set of business processes, the wrong vendor can be selected.

Well, I'm sure there are more reasons, but I'll leave it at that for now.
But the picture isn't that bleak. There are ways around the problems above, and exciting approaches that will not only make POCs better, but actually make them effective and useful...a topic for another blog entry.

Identity Management Solutions 101: Password Management

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 Password Management. 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:	Self-Service Password Reset, SSPR, Password Synchronization
Function:	Empowering the end user to manage their own passwords (without stickies!). To enable users to reset their own passwords to target systems by first correctly answering a series of challenge/response questions through an application. To enable synchronization of passwords across heterogeneous systems.
Misc. Facts:	Password Management capabilities are accomplished by different technologies. Some provisioning vendors will provide this capability, while others provide it as a standalone application. ESSO (Enterprise Single Sign-On) vendors provide this capability, although typically only to Active Directory.
Business Benefits:	Real ROI. According to this article, each call to helpdesk costs the organization $22 Central place to manage password policy Reduce the load on helpdesk by up to 30%
Use Cases:	After 2 weeks on vacation, a user forgets their password...SSPR! An end-user is required to change their Windows password. Changing it changes passwords to all other systems. A road warrior is on the road in a hotel, and forgot his/her password. Clicks on the "Forgot my PW" link on the logon screen, and resets the password. IVR - Change your password over the phone.
High Level Architecture:	For password management that is bundled with provisioning products, the architecture is very similar to the provisioning architecture. Other components may include a Windows GINA wrapper, and a DLL that sits on Domain Controllers.
Caveats:	Most products perform uni-directional synchronizations, which means that if native password resets in target systems are performed, passwords will get out of sync.

Identity Management Solutions 101: User Provisioning

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 User Provisioning. 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:	Automated Provisioning, Account Provisioning, Provisioning
Function:	Simply put, it's a fancy term for creating accounts in various systems. Typically, it's for creating user accounts, but can also be used to create any digital account, including computer accounts, badge accounts, etc.
Misc.Facts:	User Provisioning is by far the most popular component of the Identity Management stack. According to Gartner, almost 2/3rds of Identity Management projects are in fact User Provisioning projects.
Business Benefits:	Huge cost-avoidance opportunities Great tool to replicate/optimize business processes Out of the box connectors to target systems Flexible framework for targets without OOB connectors
Use Cases:	Employee onboarding/offboarding to all targets Contractor onboarding Employee self-service capabilities to update their own profile Bulk offboarding/deprovisioning Emergency offboarding/deprovisioning Approvals based onboarding per target system
High Level Architecture:	Typically, there is a server that stores the business logic, and connectors to various target systems that typically reside on the same box. Some legacy systems may require an agent to be stored on the target systems themselves. Also, there is a datastore (some vendors provide their own, others utilize AD or an existing data store).
Caveats:	Don't understate the business process analysis part of this project. It takes longer than you expect, but can make all the difference in the world for the success of your project!

 

 

Identity Management Consulting: 4 Things To Consider When Selecting a Vendor

Selecting the right Identity Management Consulting firm to aid your company's Identity Management initiative can be absolutely critical to your success. Unfortunately, when Identity Management initiatives fail, they tend to fail big - primarily because of the pervasive nature of the technology and related business processes. Here are a few things to consider before making that critical decision of which firm to work with:

1. The Identity Management Roadmap: Most Identity Management initiatives are not seeking to solve a single identity management problem, but rather looking to comprehensively manage identities in their corporations, often times even manage the identities of partners and clients. If this describes your initiative, then you should be prepared for a long road ahead, typically spanning years rather than months. A good Identity Management Consulting Firm will have experience aiding corporations in your vertical defining an Identity Management Roadmap, taking into consideration your business objectives, technical objectives, as well as a healthy understanding of how various identity management components interact. The Identity Management Roadmap will ensure commitment to the identified objectives and prevent scope creep.

2. It's More Than Just Identity Management Software: The most common mistake made by organizations is to treat the project as just technology. Identity Management is primarily about automating business processes related to managing digital identities. The right firm should have real-life experience in Business Process Management (BPM) as it relates to identity management workflows. Firms with this experience will make the difference between simply installing software and putting a true overall solution for your organization that will actually be utilized.

3. But Don't Forget About the Identity Management Software: Eventually, after analyzing existing processes, optimizing them, mapping the processes to technology and putting together a solid identity management architecture, ultimately you need a firm that understands the specific Identity Management Software that you have selected to implement. Look for a company that has numerous implementations, and validate that by following up on more than 1 or 2 references. Ask references the tough questions, such as regarding difficult technical problems they were able to solve, the quality of their consultants, and the efficacy of their implementation methodology.

4. What About Supportability?: The most often overlooked aspect of an Identity Management project is post-implementation support. Once the Identity Management infrastructure is in place, who will support it? The Identity Management Consulting firm should ask the right questions regarding your organizations capability in regards to post-implementation support, and take that into consideration when proposing a solution. Firms that offer an Identity Management Managed Services offering should be given special preference, due to their obvious expertise in aiding organizations manage Identity Management systems at the time its needed the most - once they have gone live.