Having one user account that works across a number of websites can save a lot of bother with joining new services.

A large proportion of website users will have some kind of Google, Microsoft, Facebook, X, etc, account. It gives us access to our email, profiles and posts, but can also authenticate users on a variety of other applications using single sign-on (SSO).

Single sign-on allows users to access a number of different services from one login. It could be an account that provides the user access to their online document store as well as their email. Behind the scenes authentication tokens do the work of logging a user in. This may use SAML (Security Assertion Markup Language), LDAP (Lightweight Directory Access Protocol), JWT or OpenID Connect.

The website that does the logging in of users is called the Identity Provider, and the sites that users get their services from are Service Providers.

There’s another way to manage single sign-on without expecting users to be signed up to a social network or search engine account first. This can be useful where services work across related websites. For example, registered members may get access to CPD events, Alumni information and training courses depending on their requirements. It may even be possible to log users into an account on a Moodle site but authenticate logins via Joomla provided there is a SAML connection, for example.

You may be most familiar with SSO in Joomla when using the the Joomla website and signing in via the Joomla! Identity Portal

The Task

I began this article while working with a client whose aim it is to link several websites that offer different services via one login. They run events and training for customers and students who don’t want to have to manage multiple accounts for effectively the same organisation.

We did some searching around for solutions and realised that it may have been better to have built the websites with user sign-ins as part of the original specification. Only that doesn’t always happen in the early phases of ongoing projects. The CPD site arrived 10 or so years after the main website which had already consumed 2 other sites.

Single sign-on was our goal. And it would be through the Joomla websites that we manage for a growing number of their users.

Getting Set Up

Finding the right solution meant dismissing the social / search engine account route. Not everyone in the client base / target market would be majorly tech-savvy so we needed something simpler that could be easily explained and carry the same branding across subdomains. Our identity server would redirect users to their events website while still carrying the same logo.

After trying various scenarios we opted for Joomla SSO, a paid extension from RolandD. Roland Dalmuder has been patient with questions about how to set up a test version of the service we’re looking for. The extension needs installing on the Service and Identity Provider websites and they need to speak to each other.

Get Ready For Part Two

And this is where I have to leave you for now. While we’ve had a lot of help so far in getting our single sign-on system setup, a few glitches / hitches along the way meant reaching out to the webhosts for assistance and this has delayed getting things working.

In Part Two I’ll go through the exact process of setting up single sign-on in Joomla with any gotchas documented. The article will also cover managing user consent.