Select OpenID Connect solution for single-sign-on

Single-sign-on (SSO) is a critical component in large enterprise architectures, either from security prospective or usability of systems. There are many different approaches to implement SSO functionality, the most common is the Windows domain authentication based approach, but that has many limitations while it is still plausible and useful for many of the companies. The limitations we should highlight are the platform limitations (desktops are fine, other devices are so limited) and extendibility (multi-factor, user profile data access). All the steps you will read are the summary of a living project executed in a large company, it was not only a l'art pour l'art activity of a boing architect.

This article describes an alternative solution, using OpenID Connect protocol, utilising Windows authentication, supporting different platforms and user channels, handling multi-factor authentication and so.

irst, some words about OpenID Connect. It has two main aspects to know. The first is, that it uses the so called "notary" approach: Authentication platform gives mandate for the actors, while each systems has to validate if the mandate shown is still usable. Validation may happen on the mandate itself, it is not necessary to go back to the authentication platform. The additional speciality of this approach is, that the mandate given cannot be revoked, the actor got it may use it till the time it is signed to be valid. The naming convention of OpenID Connect declares this shared responsibility: actors asked for authentication reflected as Relying Party (RP), the authentication platform is called Openid Connect Provider (OP) - Provider and relying party.

There is an alternative of OpenID Connect (OIDC), SAML, which also can be used for similar situations, but OIDC is simpler to use, therefore the solution will be more clean on longer run. On the other hand SAML implementation has the typical problem of customisations either on the protocol itself but also on the client side, how to interpret SAML messages.

Accepting the OIDC is a good solution, the next topic is to find and existing solution. The best start line is the page, which shows many different potential solutions including paid and open-source softwares too. I ran through many of them, reading the available materials and below you can see the results. We go thorough step by step, therefore you can understand the reasons behind the final suggestion of mine, and on the other hand you can tune the steps of selection wherever you need, and potentially select other solution, better fits to your needs.

Pre-filtering of solutions

At the first run targeted 6 solutions were selected from the page above. The filtering condition were to find free open-source software (FOSS) solutions, which are supporting wide range of OpenID flows and has the capability of identity brokering (e.g. Facebook login) and two-factor (multi-factor) authentication.

The reason of filtering for FOSS solutions was, that we Customer requirements pointed potential customisations either on data model of identities or on the field of functionalities. Customisation of commercial software is not suggested (as usual), therefore they were closed out. In addition FOSS is a cheaper start, which may be extended by commercial support assuming a product have it offered - this also means, that the option of commercial support was also important to have.

Technology aspects

Pre-reading the accessible documentation gave high-level bias of the solutions, like poor documentation, Windows only environment, or missing stable version.

  • Evaluate short- and long-term needs
  • Java-based, stable solution
  • Good references
  • Ready to enhance 

Expected customizations to count (some of them may exists in existing solutions):

  • Session termination
  • Extra attributes for data model
  • Login classification
  • Many different login flows with multi-step identification (non-unique user identifier problem)

Principles for evaluation

The following list describes the title of principles used for evaluation. The titles themselves are clear, while it is important to have details and rational for principles in a live environment. The details of these principels are out of the scope of this article, but searching the word 'principles' you may find many articles here in the portal.

  • Minimise complexity
  • No functional duplication
  • Avoid data duplication except it gives you extra capability
  • Encrypt as necessary but not more
  • Do not customise OOB, except open-source
  • Synchronous operation is a must if the response has a meaning for the caller.
  • Backup separation – backup to independent nodes
  • Critical service availability is 99.9+%

Pre-filtered list of solution

After reading the high-level materials the following list of solutions are nominated for further analysis.

  • Gluu
  • Gravity Access Management Server
  • KeyCloak
  • OpenAM
  • Verify My Identity
  • WSO2 Identity Server

Still using the openid portal extended by the product portals I read through the details of the solutions, summarising the most important aspects found. (+) lines highlighting positive aspects, (-) lines are cons to the solution, while (?) lines are ambivalent: some of those may by disadvantage or advantage at the end. The potential advantage will be real ones, if the scope is extended on the top of SSO.


  • Complete solution, correct details
  • Well-documented
  • Ready to enhance
  • Local copy of identity records is a must


Gravity Access Management Server

  • Fuzzy approach
  • Documentation is relatively poor
  • It has API management (main focus of the product – it may be useful for future for potential microservice authorisation)



  •  Focusing on paying version (Redhat covered)
  • Not suggested for customisation
  • Great references



  • Old complex model, far to be future proof
  • No option for enterprise support
  • Not suggested for customisation - complexity
  • Great references


Verify My Identity

  • Brand new
  • No stable version
  • No real references


WSO2 Identity Server

  • Well-prepared solution
  • Ready to enhance
  • API management included
  •  .NET focused
  • The only app server it runs on is WSO2 Carbon


Short list

The short list is Gluu and KeyCloak. Gluu has better helicopter view in documentation with all the necessary details. KeyCloak has very detailed documentation with harder starting steps to understand and try.

Gluu declares that identity caching is a must, while at KeyCloak it defined as optional (frankly speaking: it is mandaatory for high-performing environments!).


Evaluation details of the short list

Both of the solutions require its own account database to use. It is mandatory for Gluu, while KeyCloak allows to use external LDAP or AD fro low performing environments. For those cases when there is no other accounts database this requirements will not be a problem at all, but in corporate cases it is usual to have Active Directory handles user logins, supporting exchange and file shares, and it plays the primary account store for operative purposes. For there cases Gluu and KeyCloak refers their account store as identity cache.

Caching data hurts the “Avoid data duplication” principle except it has real meaning on capability. On the other hand, batch synchronisation to the cache has some important advantages, which increase the non-functional capabilities:

  • Cache minimises external dependency
  • There is no time-consuming data conversion on the real-time, response time critical interfaces
  • Data errors has no effect on user/customer facing channel, they handled in course of synchronisation
  • Load sizing is independent from identity stores
  • Cache can take over authentication store role too (key federation), but authentication can stay on AD
  • Cache fulfils new identity store role for the future needs

Finally, the expected higher availability, the lower response time and the lower dependency on external systems are enough extra value to approve the existence of caching!

The evaluation below uses the same syntax for aspect highlighting.

Gluu evaluation

  • The documentations have the appropriate details, and they start with great overview information, which helps to understand each of the domains the product serves.
  • It allows to use many different session stores. For HA environments it is capable to use either single Redis node or a Redis cluster. Redis is a well-known, proven, widely used key-value store solution, which is a great selection for session store functionality.
  • Well-defined roadmap.
  • User sync is a must, while the local LDAP for identity store has important advantages, which is discussed at caching
  • Auditing and logging are good enough, but has no extras
  • Wide range of 2FA solutions are accessible, covering Customer needs
  • 3rd party identity federation is included (like FB login)
  • UI customisation is simple and is not affected by upgrades.
  • There are no multilingual end-user user pages.
  • There is no user language selector function.
  • There are no details of security risks
  • Latest major release is certified at
  • There is option to buy commercial support
  • The product has the option to use one single DB covering identity and session store function for extreme high performance need (Couchbase as paid option)



  • The documentation is very detailed, but it does not have those layering which would make them useful. It means, that each set of information should be dug from the details of bits and bytes.
  • Session store solution is Infinispan. Most of its references are hidden infrastructure like, hard to get support, and hard to learn.
  • No clear roadmap.
  • User sync is not a must, it iterates through the providers in the course of AA (first failure stops the iteration; there is no clear order definition). If you should use extended attributes, local user record will still be necessary. It uses on-the-fly sync by default, which means the first AA request stores the identity record locally, which never will be updated (this method should be switched off carefully)!Additional sync (periodic changed or full is configurable separately). It prepared to sync back changes of identities, which is risky and must be switched off! It strongly counts on the modification of local identity instances, since its main approach is to use local ID store with registration while synchronisation is just an add-on. One crazy example of its approach is, that locally manages user lockouts, while it has no solution to handle external passwords.
  • Auditing and logging is so matured. One example of extras: it can be configured to notify the user, if an event affects him.
  • 2FA supports only FreeOTP-t and GoogleAuthenticator, which doesn’t meet with Customer needs.
  • 3rd party identity federation (FB login) requires external plugin to use.
  • UI customization is simple and is not affected by upgrades. It uses Themeable for UI themes.
  • Supports multilingual end user UIs by default.
  • There is no user language selector function
  • Great details of security risks handled
  • The latest release certified at is 2.3.0, while 6.0 is accessible to use.
  • There is no commercial support, while it can be covered by special Redhat support package options.



Log in to comment

Architect Archers

Architect Archers are Enterprise Architect professionals and mentors.

Our mission is to build Your Archers team while defining, aiming and hit your Enterprise Targets.

© 2017 Architect Archers