Joomla! World Conference 2026

In part one I covered reasons why we might want to use Single Signon and how we could set this up in Joomla. This time I’m detailing how I set things up and got myself signed into several websites using the same credentials authenticated by one site.

Here’s some terms we will use and the simple process they follow:

Service Provider (SP)
Identity Provider (IDP)
Single Signon (SSO)

  1. When a user logs in to a service from their web browser they do so from an SSO login page

  2. The user’s credentials are sent to the IDP for authentication

  3. When authenticated the IDP provides a SAML token and the user is sent back to the SP where they can access the service using the the token as authentication

The service provider reads the metadata of the identity provider and vice versa

On the service provider site you add an identity provider profile and on the identity provider site you add a service provider profile

I’m not one for just diving in, however intuitive a system appears to be.  Fortunately the SimpleSAMLphp documentation as a lot of information and it’s the core of the extension we installed and it lives in Libraries within Joomla when RO Single Sign On is installed and enabled. 

Working with my client we are aiming to create an Identity Provider site that will provide authorisation for several other sites, which are the Service Providers, ie where the user will be able to access their information having logged in. In this case it’s details of events they have booked, and courses they have signed up for. What I needed to understand was the actual settings for each.

In the extension the first thing I see is the dashboard which helpfully includes a checklist of items that need configuring and enabling, including the Authentication plugin and System plugin.

I chose to install the Identity Provider first, as logically this is where every other site would connect to for authentication. I also created 2 new sites running Joomla 6.1 one called identity.{domain} and the other sp.{another-domain}

Configure the Identity Provider

Install the RO Single Sign On extension and enable the Authentication plugin.

While it’s not quite in the order of menu options, create the secure certificates first. Under Certificates click New and follow the details in the form, including adding a Password which you will need later on, so remember what it is! All fields are mandatory.

I named my files dansso.pem and dansso.crt then clicked Generate Certificate.

Frustratingly I got a message saying: COM_SSO_CANNOT_CREATE_CERTIFICATE

I assumed this was about making sure the plugins mentioned in the Dashboard Checklist are enabled first, but actually toggling the Inline Help I got comments next to each form element and it turned out my interpretation of Country was wrong and I needed to Enter the 2-digit country code

With that corrected my 2 certificate files were created and I could indeed see them in the libraries/simplesamlphp/cert folder.

Under Single Sign On Configuration I set the Base URL Path to be sso/ then followed the form to add:

  • Administrator password

  • Secret Salt - this will error if not changed from the default value

  • Technical contact details

  • Set the slider to yes for Enable Identity Provider

Identity Provider Profiles

I named my Profile DanIdentity and the SAML protocol was already selected. Toggling inline help was again very helpful at this stage.

I had to guess at the location of the metadata but having set the symlink for sso/ from the instructions I went for https://{domain}/sso/metadata-generated

The login URL is set in the menu manager by choosing the RO Single Sign On menu item type and the profile we created previously. 

Having created certificate files, this is where we get asked to select them and the password. The Sign Logout and Sign Metadata options were left and I clicked Save.

So good so far. I went back to the Identity Provider Profile and found the Service Provider Metadata URL was created. Clicking this did indeed download the metadata XML file. 

Configure the Service Provider

Having got over a few gotchas with the Identity Provider setup I felt like this should be a quicker setup on the Service Provider site.

The documentation for Setup Joomla! As a Service Provider looked different as it relies on the Identity Provider having been setup, so I think the order I chose for setup was correct.

Creating the certificates was very quick now I knew about the country code.

I named my service provider with a meaningful name then set the URL where its metadata would be found. Setting the Output Folder to the web address only and format to Flat File.

Toggling Inline Help again is very helpful here as I wasn’t sure about Expire Days. Setting to 0 means never expire.

Finally I set the certificates and clicked Save.

For the Service Provider to use the IDP site for login the plugin for Single Sign On needs to be enabled. The link for that is in the RO Single Sign On Dashboard page. This prevents the user logging into the site but instead being redirected to the IDP for authentication.

There is a “safe word” to add to the login URL in case you need to login to the SP site. On other services you might find a parameter like ?saml=off works

I also found that not being able to login I was getting XML / Metadata errors

You can check settings in /sso/module.php/admin/ which is a good place to start but refreshing metadata is a good option on the Identity site or flushing the cache also worked.

What We Did Next

Our particular use case is to provide users with one account where they might book a training course or seminar but also to access their course material which is managed elsewhere. Not all of these resources are managed in Joomla, so we connected the organisation’s Moodle site to the Identity Provider as well.

Moodle has a SAML plugin so we added that, then configured it to use the Identity Provider and then found the metadata URL which was then pasted into a Service Provider profile on the IDP site. We have a mixture of username types so some are usernames, some use the email address. For uniformity I mapped Joomla Email to Moodle’s email and also set it to create new users if an account didn’t exist there. 

Mapping fields

If the above actions sound easy, they were, after having jumped through a few hoops to upgrade Moodle. I created a user on  the Moodle site that matched the username and email address on the IDP. A user account is needed to be able to assign courses to it.

Changing the login theme

When I asked the extension creator, Roland, about changing the layout of the login page he pointed me to some documentation entitled Theming the SimpleSAML user interface with a comment that: “...You can style the identity login but that is not the Joomla way” ie don’t overwrite system files. The documentation takes a bit of following, but if you’re happy to search for files in /libraries you’ll soon realise that adding a module of your own and then creating a themes folder within is quite simple. After adding details to the config.php within SimpleSAML you’re ready to add assets such as CSS to the public/assets folder.

Given that I was trying to emulate the company style of 2 existing websites I did try referencing UIKit CSS and JS files. There are however security headers within SimpleSAML which can prevent external files being called, but I was able to download and reference UIKit CSS from within the _header.twig file that I had copied to my custom theme.

Updating Credentials

There’s always the possibility of forgetting your password. By default the SSO setup doesn’t provide self-service password resetting which could mean a lot of work for the helpdesk, and also making sure that new passwords are transmitted in a safe fashion.

We’ve already made a custom layout using the theming method discussed earlier. If you create a Password Reset menu item in the Identity Provider then adding a simple link back to that in the base.twig file will add that functionality.

Consent

There is an available module that handles consents for storing and processing of personal data on the Service Provider sites that the IDP provides access to. You can find details for Consent Simple Admin on the SimpleSaml Modules page. It’s something you’ll find on the Joomla Community login and worth checking what’s covered. I was pleasantly surprised to see “This consent allows the Joomla project to use your mailing address to send items (like rewards, stickers, t-shirts, holiday greetings).” as one option and I’m hoping I haven’t missed anything in the mail.

Consent is something to consider when creating a service that covers multiple sites but it’s out of the scope of this article.

Conclusion

Everything covered here has been done via a test environment so my next step, now that I’m happy with the setup, is to install Single Sign On on the client site where we can look at several thousand users potentially logging in to one of several events sites and a Moodle site, all with the same credentials. 

About the author

Dan has been building websites since 1995 and started developing websites with Joomla in 2009 after dabbling with Mambo. A sometimes attendee of JUGL and other networking groups, he runs a web development business (DJA Online Services), collaborating with developers and designers around London and the South of England. In his spare time Dan is a baker and musician, and runs a gig listing website called Music On My Doorstep.

Visit website

Some articles published on the Joomla Community Magazine represent the personal opinion or experience of the Author on the specific topic and might not be aligned to the official position of the Joomla Project

Comments