Matt has implemented Single Sign On authentication for more than 20 systems using all the most popular schemes:
- SAML2
- OAuth
- OpenId
Fortunately these days when implementing many SaaS solutoins, enabling Single Sign On is a much more streamlined experience. The industry has generally coalesced on a viewpoint that an email address, whilst not immutable (e.g. consider a name change after marriage), is close enough that the benefits of its omnipresence as an identifier contained in almost every system that maintains user accounts far outweighs the operational overhead of having to make the occasional change across multiple systems.
From experience I concur with this view having tried various different approaches including some which are architecturally more pure - but less intuitive both to end users and operational teams.
There are plenty of opportunities still to make mistakes when implementing Single Sign On. Here are some of the considerations:
- Does your service provider (The system the user wants to use) enable user accounts to be created automatically at first access? This can reduce your user admin overhead. If so, should you leverage this? The right answer depends a lot on what other onboarding activities may be required in addition to just creating the user account (e.g. is there an appropriate default role for a user - or does that still need to be assigned before the account can be used effectively).
- Are there additional attributes that you would like to sync from your Identity Management system to the Service Provider. i.e. as part of the message from the IdP to the SP which authenticates the user, do you want to also pass across details such as their department, phone number, line manager etc. Some applications can make good use of this capability to significantly reduce the amount of duplicate data maintenance that is necessary (and of course, in practice just often doesn’t happen leading to out of date information in any system where there isn’t a powerful driving force embedded in the business processes related to the use of that system which ensure any inaccuracies are identified and corrected).
- IdP and SP systems have still not standardised on enforcement of mandating that responses are digitally signed. A lack of understanding of the capabilities and requirements of both the particular IdP and SP in this regard and understanding how to configure correctly can still lead to long delays in what should otherwise be a simple SSO integration between systems.
Additionally there are still plenty of applications that have not simplified their implementation of Single Sign On. If you get Matt involved he will ensure that you have a fast and smooth implementation giving you the option to leverage as much (or as little) of the capabilities of the SSO protocols as appropriate for your business.