Expanding your vision of an SSO project: objectives and good practices to maximise the benefits

When we hear SSO project, how often do we assume it is simply about setting up a Single Sign-On system to eliminate the need for passwords and simplify things for users?

As IAM specialists, we keep on saying it: SSO or Single Sign-On goes much further than that! SSO projects today are more about standardisation and identity federation using standards such as SAML or OpenId Connect.

This post aims to develop what is understood by ‘SSO project’ and give you some tips to establish the guidelines of your project and to implement it according to your objectives.

What are good practices for a successful SSO project?

First of all, take the time to ask yourself the right questions: why do I want to implement such a project? What are the advantages and who are the priority beneficiaries? What objectives do I want to achieve? Are they motivated by a need for security, user convenience or regulatory compliance for example?

Too many organisations today set out without having established their needs. By asking the right questions you will be able to define the scope of your project.

Wanting to do everything in one go is unrealistic! Focus first of all on the main objective you want to achieve and on the aspects that will generate ROI. Splitting an SSO project will make your scope quickly achievable.

Once you have established your need, I strongly recommend that you map out the applications to take into account, the types of technology used (web applications, heavy clients, etc.) and the flows by which users access them.  

These days we work on IT systems with an extremely vast and open range of applications, user usage scenarios, authentication methods, access procedures, work environments, etc. This is why we should absolutely not think of SSO simply as a ‘Single Sign-On technology to eliminate the need for passwords’! It is much more than that: it needs to be able to combine the technological approaches in order to adapt to what already exists and to a heterogeneous information system. There are therefore generally different approaches to SSO: Web SSO (or Web Access Management) and identity federation if working only on the web, Enterprise SSO (or eSSO) to protect workstations and fat client applications, and finally mobile SSO for mobile environments.

The more detailed your analysis, the more you will later gain in effectiveness. For example, you can develop the mapping of your applications by determining their level of sensitivity, thus enabling you to determine whether strong or adaptive authentication is necessary. This will enable you to incorporate security and ergonomics right from the start of the project.

A bit of advice: adopt a simple and pragmatic approach. The more complex the implementation, the more difficulties you will have with operational maintenance over time.
For the application’s sensitivity criteria, you can for example consider three levels:

• Non-sensitive applications for which simple authentication will suffice,
• Sensitive applications for which strong authentication will regularly be required,
• Critical applications for which strong multi-factor authentication will systematically be required.

At Ilex we work with many organisations whose objective is to go for adaptive authentication methods, combining both security and user convenience. This is particularly the case for Natixis, a French financial establishment operating internationally, who took this all the way by definitively eliminating the use of passwords on the bank’s applications in favour of strong authentication methods adapted to the uses of employees. This is the ‘Kill The Password’ project, a great project for which I recommend reading the customer story.

Why is the role of end users crucial in an SSO project?

If any role should not be overlooked at any stage, it is the role of your user!
The methodology for deploying the SSO project generally involves different stages:

1. Implementation of a test development platform.
2. Conception phase which is a chance to deal with all the technical issues and particularly integration with the existing technological environment.
3. Pilot or POC (Proof of Concept) deployment phase with tests of uses on sample groups of users to progressively integrate all the applications.
4. Final phase of launch and general deployment.

Involve your users at each stage of your SSO project.
This starts from establishing the project guidelines and the functional specifications phase. We recommend that you work in workshops with the application managers who know the professional uses or, if possible, directly invite a panel of end users in order to get an insight into the reality in the field.

Working with a panel of users will enable you to take into account usage scenarios and the way in which users connect (do they change workstation in some situations for example…). The introduction of Single Sign-On must fit perfectly into their normal way of working and offer the best ergonomics for their authentication procedure.

For example, if you integrate multi-factor authentication into critical applications, you would need to anticipate the different usage scenarios and degraded modes that users require in their everyday operations. You must not block them and cause the problems or frustrations to outweigh the benefits.

In the deployment phase, a pilot run with end users helps to verify the relevance and reliability of what has been implemented in a limited scope. Among our clients, Leroy Merlin for example first deployed its SSO project in a pilot store in order to test the new user experience offered by the Sign&go Global SSO solution in real conditions. Following positive feedback from users, the solution could be deployed across all of the company’s stores.

Involving end users in the SSO project enables you to better anticipate the necessary changes and to get them using the new deployed solution more easily. Management of change is a key point that should not be overlooked: any new SSO solution should be perfectly adapted to users’ varied uses, but also supported by a communication and awareness-raising campaign.

How are SSO projects evolving today?

Extended enterprise, the range of applications and environments and the real challenges of regulatory compliance that are very present today are all factors that see SSO projects evolve towards more standardisation. This is why identity federation is becoming more and more necessary when implementing Web SSO architecture that uses standard and standardised protocols such as SAML, OAuth or OpenID Connect, including for access to SaaS, Cloud and mobile applications.

When launching an SSO project, it is important to adopt a holistic vision and to think of ‘pooling’ and ‘system architecture’. A global SSO solution enables you to cover your short-term needs and also leave you the capacity to address your other medium and long-term needs, all through a scalable and iterative approach.