Implementing Customer Single Sign On at Large Companies
The Biggest Obstacles and Strategic Decisions
As you may know when you’re working in Tech (like me) you are probably at least somewhat familiar with the high failure rate of big tech projects and the most important reasons why. Since I’ve had the privilege of being the project manager of a very large and SUCCESSFUL (boasting a bit, sorry) tech project – implementing Customer Single Sign On (SSO – the means by which you can use one login for multiple apps / services) in a very large organization – I’d like to share a few learnings and potentially speed up the journey of others.
Learning one: Start with a Customer Journey, ASAP!
Easier said than done however, as in my project the Identity and Access Management (IAM) teams (customer and corporate IAM) were located in the security department. Security should act as a business enabler (hopefully), but traditionally has no direct customer facing touchpoints, and Single Sign On does have a frontend. That means SSO requires customer experience journeys and design, and that expertise was not present in the security department. The first drafts of the SSO project were written from a very security and tech-heavy perspective – and those were not convincing to upper management, where each step of a Customer Journey involving nearly 50 million customers is meticulously monitored and thought-out.
Learning two: Identify large conflicting interests at the start of your project
A massive conflicting interest in my project was the fact that one Customer Facing Application (CFA) was using Social Login (Facebook) and the other three were not. With SSO in mind, the technical options were to either enable Social Login for all, fully turning it off, or having a work-around to support Social Login on only one platform. Stripping it down to a technical choice was however missing the point of how large and complicated the decision actually was on a strategic level. If you’re a retail company, do you want Facebook to be aware of (a portion of) your customer base, and be able to market that data to your competitors? How much revenue is being generated by impulse buying via Social Login, as it does remove the customer obstacle of creating a full account? What if Facebook has (another) reputational event, do you want to be associated with it by presenting their login as an option? The appropriate level of decision making in this case went all the way up to the Management Board, and required the involvement of Senior Vice Presidents of multiple organization-spanning departments such as Security, the Legal department and Marketing to name a few.
There are many more points to be made, but it should already be clear from the above, that implementing SSO is not really just about the Technology itself.
I’ll leave this blogpost with a few questions:
1. What is the problem you want to solve, and what is the experience you are trying to sell?
These are two questions you should be able to answer off the top of your head for each Tech project, and it is very applicable for Customer SSO. I recommend not being blindsided by technical or security advantages, but focus first on visualizing (with mock screens) SSO opportunities from a customer interaction perspective. These may include cross-CFA marketing coupled with seamless transition between your apps, or removing unnecessary steps in a customer journey. An audience warmed with visual opportunities.
2. Where is your Identity and Access Management team located in your organization?
Is this team located centrally (like a Security or overarching Technology department), or embedded within a Customer Facing part of the organization? Both have big advantages and disadvantages impacting your SSO project. The advantage of having your Identity and Access Management team at a customer-interfacing part of your organization is having access to product specialists with customer-behavior knowledge (required for testing your new IAM-interfaces and seizing your SSO opportunities), while the advantage of having your IAM team located at a centralized location (like overarching Tech, or Information Security) is your ability to place a core piece of technology most central to your infrastructure and security. This makes for easier troubleshooting, security hardening and writing IAM security policies to deal with your hackers, BOT-attack problems etcetera.
3. What are the differences in the Registration and Login process (screens and flows) between your apps?
In large organizations, seemingly small differences can have large consequences. As I’ve mentioned, Social Login in one app but not another presents a strategic decision-making challenge, but other differences – such as attributes like gender preference and name – might be asked at registration in one CFA but not another. I recommend keeping your SSO registration and login screens as clean and simple as possible, both in UI and number of attributes. An unchanging basic design with only email and password (and Multi Factor options if required) for establishing an identity suffices, and should become the trusted entry point for all customers across all your applications. Profile attributes (such as age, gender preference, address etc.) should be located (and stored) elsewhere, as they are not used as ‘key to the kingdom’. As building up and enriching Customer Profiles is however a business driver, smart IAM teams or products should of course be able to assist in a customer profile journey, if possible, for example via ‘progressive profiling’.
Onno de Kamper
Senior Architect & Program Manager
Onno de Kamper is a Senior Architect & Program Manager with extensive expertise in Identity & Access Management (IAM). In the past he has managed large IAM and Security related IT projects with his broad knowledge and experience on both operational and strategic level. Onno worked abroad for many years and during previous projects, Onno has led project teams in complex international IT environments.