Joomla als Single Sign-On instellen: Deel twee

In deel één heb ik uitgelegd waarom je Single Sign-On (SSO) zou willen gebruiken en hoe je dit in Joomla kunt opzetten. Dit keer beschrijf ik hoe ik de configuratie heb uitgevoerd en hoe ik mezelf met dezelfde inloggegevens op meerdere websites heb aangemeld, waarbij de authenticatie door één centrale website werd verzorgd.

Hieronder volgen enkele termen die we gebruiken en het eenvoudige proces dat daarbij hoort:

• Service Provider (SP)

• Identity Provider (IdP)

• Single Sign-On (SSO)

Wanneer een gebruiker zich via een webbrowser aanmeldt bij een dienst, gebeurt dat via een SSO-inlogpagina.

1. De inloggegevens van de gebruiker worden naar de Identity Provider (IdP) gestuurd voor authenticatie.

2. Zodra de gebruiker is geauthenticeerd, verstrekt de IdP een SAML-token.

3. De gebruiker wordt vervolgens teruggestuurd naar de Service Provider (SP), waar toegang wordt verleend op basis van dat token.

4. De Service Provider leest de metadata van de Identity Provider en omgekeerd.

5. Op de Service Provider maak je een Identity Provider-profiel aan en op de Identity Provider een Service Provider-profiel.

Ik ben niet iemand die zomaar ergens induikt, hoe intuïtief een systeem ook lijkt. Gelukkig bevat de documentatie van SimpleSAMLphp veel nuttige informatie. Dit is bovendien de kern van de extensie die we hebben geïnstalleerd. Wanneer RO Single Sign On is geïnstalleerd en ingeschakeld, bevindt deze zich in de map Libraries binnen Joomla.

Samen met mijn klant wilden we een Identity Provider opzetten die authenticatie verzorgt voor meerdere andere websites (de Service Providers), waar gebruikers na het inloggen toegang krijgen tot hun gegevens. In dit geval gaat het om informatie over geboekte evenementen en cursussen waarvoor zij zich hebben ingeschreven. Wat ik vooral moest begrijpen, waren de juiste instellingen voor beide rollen.

De Identity Provider configureren

Na installatie van de extensie is het eerste scherm het dashboard. Dat bevat handig een checklist met onderdelen die nog geconfigureerd en ingeschakeld moeten worden, waaronder de Authentication-plugin en de System-plugin.

Ik besloot eerst de Identity Provider te installeren, omdat dit logisch gezien de centrale authenticatieserver is waarmee alle andere websites verbinding maken. Daarnaast heb ik twee nieuwe Joomla 6.1-sites opgezet:

• identity.{domein}

• sp.{ander-domein}

Installeer de RO Single Sign On-extensie en schakel de Authentication-plugin in.

Hoewel dit niet de volgorde van de menu's volgt, raad ik aan eerst de beveiligingscertificaten aan te maken. Ga naar Certificates, klik op New en vul alle verplichte velden in. Vergeet vooral niet een wachtwoord op te geven; dat heb je later opnieuw nodig.

Ik gaf mijn bestanden de namen dansso.pem en dansso.crt en klikte vervolgens op Generate Certificate.

Tot mijn frustratie verscheen de foutmelding:

COM_SSO_CANNOT_CREATE_CERTIFICATE

Mijn eerste gedachte was dat de benodigde plugins nog niet waren ingeschakeld. Nadat ik echter Inline Help activeerde, verschenen er toelichtingen bij elk veld. Daaruit bleek dat ik het veld Country verkeerd had geïnterpreteerd: hier moest de tweeletterige landcode worden ingevuld.

Na deze correctie werden beide certificaatbestanden succesvol aangemaakt en waren ze zichtbaar in:

libraries/simplesamlphp/cert

Onder Single Sign On Configuration heb ik vervolgens het Base URL Path ingesteld op: sso/

Daarna vulde ik de overige instellingen in:

• Administratorwachtwoord

• Secret Salt (dit moet worden gewijzigd; de standaardwaarde veroorzaakt een foutmelding)

• Gegevens van de technische contactpersoon

• Enable Identity Provider op Yes gezet

Identity Provider-profielen

Mijn profiel kreeg de naam DanIdentity. Het SAML-protocol was standaard al geselecteerd. Ook hier bleek Inline Help opnieuw erg nuttig.

Ik moest gokken waar de metadata beschikbaar zou zijn. Omdat ik eerder volgens de instructies een symlink voor sso/ had ingesteld, koos ik voor:

https://{domein}/sso/metadata-generated>

De login-URL wordt ingesteld via de Menu Manager door een menu-item van het type RO Single Sign On aan te maken en daarbij het zojuist aangemaakte profiel te selecteren.

Omdat de certificaten inmiddels bestonden, kon ik ze hier selecteren en het bijbehorende wachtwoord invoeren. De opties Sign Logout en Sign Metadata heb ik ongewijzigd gelaten en daarna op Save geklikt.

Tot zover verliep alles goed.

Toen ik terugging naar het Identity Provider-profiel, bleek de Service Provider Metadata URL automatisch te zijn aangemaakt. Door daarop te klikken werd inderdaad het XML-bestand met de metadata gedownload.

De Service Provider configureren

Nadat ik enkele valkuilen bij de Identity Provider had opgelost, verwachtte ik dat de configuratie van de Service Provider sneller zou verlopen.

De documentatie voor Setup Joomla! As a Service Provider ziet er anders uit, omdat deze ervan uitgaat dat de Identity Provider al bestaat. Achteraf bleek de gekozen volgorde dus de juiste.

Het aanmaken van de certificaten ging nu snel, omdat ik inmiddels wist dat de landcode uit twee letters moest bestaan.

Ik gaf de Service Provider een herkenbare naam en stelde de URL in waar de metadata beschikbaar zouden zijn. Vervolgens zette ik:

• Output Folder op het webadres

• Format op Flat File

Ook hier was Inline Help erg behulpzaam, met name bij het veld Expire Days. Een waarde van 0 betekent dat de metadata nooit verlopen.

Daarna selecteerde ik de certificaten en sloeg de instellingen op.

Om ervoor te zorgen dat de Service Provider de Identity Provider gebruikt voor authenticatie, moet de Single Sign On-plugin worden ingeschakeld. De snelkoppeling daarnaartoe staat op het dashboard van RO Single Sign On.

Hierdoor kunnen gebruikers niet langer rechtstreeks op de Service Provider inloggen, maar worden zij automatisch doorgestuurd naar de Identity Provider.

Er bestaat wel een zogenaamde safe word die je aan de login-URL kunt toevoegen wanneer je toch rechtstreeks op de Service Provider wilt inloggen. Bij andere SAML-oplossingen wordt bijvoorbeeld vaak een parameter als ?saml=off gebruikt.

Ik merkte daarnaast dat ik, zolang ik niet kon inloggen, regelmatig XML- of metadatafouten kreeg.

Een goede plek om de configuratie te controleren is:

/sso/module.php/admin/

Daarnaast hielp het vaak om de metadata op de Identity Provider opnieuw te verversen of de cache te legen.

Wat we daarna hebben gedaan

Ons doel was gebruikers één centraal account te geven waarmee zij zowel trainingen of seminars kunnen boeken als toegang krijgen tot lesmateriaal dat elders wordt beheerd.

Niet alle systemen draaien op Joomla. Daarom hebben we ook de Moodle-omgeving van de organisatie gekoppeld aan dezelfde Identity Provider.

Moodle beschikt over een eigen SAML-plugin, die we hebben geïnstalleerd en geconfigureerd om de Identity Provider te gebruiken. Vervolgens hebben we de metadata-URL uit Moodle gekopieerd naar een Service Provider-profiel op de Identity Provider.

Binnen onze omgeving worden verschillende typen gebruikersnamen gebruikt. Sommige gebruikers loggen in met een gebruikersnaam, anderen met hun e-mailadres. Om dit te uniformeren heb ik het Joomla-e-mailadres gekoppeld aan het e-mailadres van Moodle. Daarnaast heb ik ingesteld dat Moodle automatisch nieuwe gebruikers aanmaakt wanneer een account daar nog niet bestaat.

Velden koppelen

Hoewel bovenstaande eenvoudig klinkt, vergde het eerst nog een Moodle-upgrade.

Daarna heb ik een gebruiker aangemaakt op de Moodle-site met dezelfde gebruikersnaam en hetzelfde e-mailadres als op de Identity Provider. Zo'n account is nodig om cursussen aan een gebruiker te kunnen toewijzen.

Het login-thema aanpassen

Toen ik aan de maker van de extensie, Roland, vroeg hoe de loginpagina kon worden aangepast, verwees hij me naar de documentatie Theming the SimpleSAML user interface. Daarbij gaf hij de opmerking:

"You can style the identity login but that is not the Joomla way."

Met andere woorden: overschrijf geen systeembestanden.

De documentatie kost wat tijd om door te nemen, maar zodra je weet waar de bestanden zich in /libraries bevinden, blijkt het vrij eenvoudig om een eigen module met een themes-map aan te maken.

Na enkele aanpassingen in config.php van SimpleSAML kun je eigen CSS en andere bestanden toevoegen in de map:

public/assets

Omdat ik de huisstijl van twee bestaande websites wilde nabootsen, probeerde ik aanvankelijk de CSS- en JavaScript-bestanden van UIKit te gebruiken.

SimpleSAML hanteert echter beveiligingsheaders die het laden van externe bestanden kunnen blokkeren. Uiteindelijk heb ik de UIKit-CSS lokaal gedownload en deze vanuit mijn eigen _header.twig opgenomen.

Wachtwoorden wijzigen

Er bestaat altijd een kans dat gebruikers hun wachtwoord vergeten.

Standaard biedt een SSO-configuratie geen selfservicefunctie voor het opnieuw instellen van wachtwoorden. Dat kan leiden tot extra werk voor de helpdesk en maakt het bovendien belangrijk dat nieuwe wachtwoorden veilig worden verstrekt.

Omdat we eerder al een eigen thema hadden gemaakt, was dit eenvoudig op te lossen.

Maak op de Identity Provider een menu-item Password Reset aan en voeg in base.twig een link naar deze pagina toe. Daarmee is de wachtwoordreset beschikbaar.

Toestemming (Consent)

Er bestaat een aparte module waarmee gebruikers toestemming kunnen geven voor het opslaan en verwerken van persoonsgegevens op de verschillende Service Providers waarvoor de Identity Provider toegang verleent.

Meer informatie hierover is te vinden bij Consent Simple Admin op de pagina met SimpleSAML Modules.

Een vergelijkbare functionaliteit wordt ook gebruikt op de Joomla Community-website. Ik vond het grappig om daar onder meer de volgende toestemming tegen te komen:

"Deze toestemming geeft het Joomla-project toestemming om uw postadres te gebruiken voor het verzenden van bijvoorbeeld beloningen, stickers, T-shirts en kerst- of feestdagenkaarten."

Toestemming is een belangrijk aandachtspunt wanneer één Identity Provider toegang geeft tot meerdere websites, maar valt buiten de scope van dit artikel.

Conclusie

Alles wat in dit artikel is beschreven, is uitgevoerd in een testomgeving.

Nu ik tevreden ben over de configuratie, is de volgende stap het implementeren van Single Sign-On op de productieomgeving van de klant. Daar verwachten we dat enkele duizenden gebruikers met dezelfde inloggegevens toegang krijgen tot meerdere evenementensites én een Moodle-omgeving.