Dit artikel betreft het inloggen via de Single Sign-On methode in Ons. Lees meer over SSO in Ons SSO: toegelicht of bekijk de SSO-methodes van externe aanbieders in Koppelen met Ons: Single Sign-On-koppelingen.
Benodigde autorisaties
Taak: Applicatiebeheer
Vereisten voor SSO-provider
Voor het instellen van SSO als inlogmethode, moet de SSO-provider de volgende technieken ondersteunen:
OpenID Connect
Om gebruik te kunnen maken van Ons SSO moet de SSO-provider gebruik maken van de OpenID Connect standaard. De meeste grote aanbieders doen dit.
Let op: er kan geen gebruik gemaakt worden van de SAML standaard.
Let op: Voor correct gebruik van OpenID connect is het voor ons noodzakelijk dat SSL/TLS sessie tickets in stand blijven tussen openeenvolgende gebruikersrequests. Het gebruik van sommige internet-proxies of deep packet SSL inspectors breken dit gedrag, wat kan leiden tot de foutmelding "SSO Session not found".
Tweefactorauthenticatie (2FA)
Voor het inloggen in Ons is minimaal tweefactorauthenticatie nodig. Als dit bij de SSO-provider is ingericht, zal Nedap hier niet om vragen. In andere gevallen zal de extra authenticatie door Nedap worden gedaan.
Om de beveiliging van gegevens te garanderen, zullen wij altijd een tweefactorauthenticatie vereisen bij inloggen. Het kan hierdoor voorkomen dat een medewerker alsnog via de toegangscode-app of SMS moet inloggen.
AMR-Claim
Om automatisch te kunnen herkennen of een aanmeldpoging gebruik heeft gemaakt van MFA, is een AMR-claim vereist. Als die niet wordt meegestuurd zal Ons altijd zelf een MFA vereisen. Bepaalde SSO-providers ondersteunen de AMR-claim niet. Om te voorkomen dat er meerdere malen MFA uitgevoerd moet worden door de gebruiker, moet de zorgorganisatie een contractuitbreiding bij ons aanvragen. Dit is een juridische bijlage waarin de oranisatie contractueel vastlegt dat zij garanderen dat voor elke Ons-sessie een MFA is gedaan (IP-whitelisting is geen valide vorm van MFA).
Google Workspace en ADFS 2016 ondersteunen de AMR-claim niet, en vereisen dus een contractuitbreiding.
SSO activeren
Bij de SSO-provider
Om de SSO bij je provider toe te voegen, moet bij de portal van de provider een OpenID Connect applicatie toegevoegd worden, met de volgende gegevens:
Redirect URL: https://any.startmetons.nl/auth/oidc/callback
Initiate login URL: https://voorbeeldklant.startmetons.nl/auth/oidc/{UUID}
De initiate login URL kan je gebruiken om direct in te loggen vanuit je eigen portaal. Deze URL krijg je beschikbaar nadat de installatie aan de kant van Nedap is voltooid. De Initiate URL is de URL die wordt gebruikt voor de SSO-knop op het aanmeldscherm. Je kunt deze URL kopiëren door met rechtermuisklik op de SSO-knop te klikken en de link te kopiëren. Deze URL kan bijvoorbeeld worden toegepast op een tegel in het portaal van de SSO-provider. Als een gebruiker die tegel gebruikt, slaat de gebruiker het aanmeldscherm van Ons over, en wordt meteen aangemeld.
Bij Nedap
Voor het aanvragen van de koppeling bij Nedap kan een ticket aangemaakt worden, daarin staat een formulier voor het aanvragen van een SSO koppeling. De volgende gegevens zijn nodig:
Client ID en Client Secret (worden door de SSO provider gegeven na het toevoegen van een applicatie).
Issuer: URL waar de OpenID configuratie publiekelijk beschikbaar is.
Voorbeeld (Google): https://accounts.google.com/.well-known/openid-configuration
Provisioning: wil je gebruikers automatisch koppelen met Ons-gebruikers
Uit - geen koppeling.
Op basis van medewerkernummer.
Op basis van e-mail.
Naam: dit is de naam van de provider, deze wordt in tekst aan de gebruiker getoond.
Tekst op de knop: dit is de naam die op de knop van het inlogscherm komt te staan. Je kunt hierin vrij kiezen, bijvoorbeeld 'Inloggen met Okta' of 'inloggen met 'klantnaam-mailadres'.
Kleur van de knop: keuze uit: groen, felblauw, donkerblauw, geel, grijs.
Volgorde: Als u meerdere SSO-Providers gebruikt kunt u de volgorde van de knoppen kiezen.
Verborgen?: Bepaalt of de knop zichtbaar is op het inlogscherm.
Zodra wij deze gegevens via het ticket hebben ontvangen, zullen wij de configuratie aan onze zijde uitvoeren. Dit kunnen we doorgaans de eerstvolgende dag doen. Hierna komt de Initiate login URL beschikbaar die je bij je SSO-instellingen kunt invullen.
Geef bij het aanvragen van een SSO-koppeling ook een telefoonnumer van een technisch contactpersoon door, zodat wij contact op kunnen nemen over de koppeling.
Het inschakelen van SSO veroorzaakt geen downtime voor de applicatie.
Configuratie per SSO-provider
Google Workspace
Voor Google Workspace hebben we (met dank aan onze klanten) een video-instructie van hoe deze ingesteld moet worden.
Okta
Volg de configuratiestap Bij Nedap hierboven om de Initiate Login URL te verkrijgen. Hiervoor heb je de Client ID en Client Secret nodig die je op het tabblad Sign On in Okta vindt:
Zodra je de Initiate Login URL hebt, kun je deze gebruiken om op het tabblad Sign On in Okta de velden Subdomain en Nedap ID als volgt in te vullen:
Subdomain: vul hier het deel van de Initiate login URL in tussen <https://> en <.startmetons.nl>.
Nedap ID: vul hier het gedeelte van de Initiate login URL in achter </auth/oidc/>.
Bij de eerder genoemde voorbeeld-URL (https://voorbeeldklant.startmetons.nl/auth/oidc/{UUID}) ziet dit er als volgt uit:
Klik vervolgens op Save om de configuratie op te slaan. Single Sign-On tussen Nedap ONS en Okta is nu ingesteld.
ADFS
Onderstaand de (visuele) instructies voor het instellen van SSO in ADFS:
HelloID
De instructie is beschikbaar op de website van HelloID. Deze informatie is enkel beschikbaar in het Engels.
Azure
Voor Azure is het zaak dat er een (multi-tenant) applicatieregistratie wordt gemaakt. Let erop dat dit op twee manieren kan. Het is de bedoeling niet een enterprise appregistratie te maken, maar een standaard appregistratie. Hierna moet er een client secret worden gegenereerd. Daarbij wordt ook een secret value gegenereerd. Deze heeft een vervaldatum. Stel voor jezelf een herinnering in wanneer deze secret value komt te vervallen, zodat je deze op tijd kunt vernieuwen (en delen met Support in een ticket). Wordt de secret value niet op tijd vernieuwd, dan kan de SSO-configuratie niet meer gebruikt worden.
Na de registratie moet de client_id, client secret value en issuer via een ticket aan Support worden doorgeven. De issuer is in de vorm van: https://login.microsoftonline.com/[uuid]/.well-known/openid-configuration.
Voor automatisch koppelen op basis van e-mailadres moeten er nog twee stappen worden uitgevoerd: ten eerste moet er onder : openid, email en profile worden toegevoegd.
Hierna moeten de volgende stappen worden uitgevoerd. Het resultaat kun je vinden in het Manifest en moet gelijk zijn aan onderstaande schermafbeeldingen:
Voor Azure hebben we op dit moment nog geen informatie hoe we op basis van medewerkersnummer kunnen koppelen.
Secret value
Stel voor jezelf een herinnering in wanneer de secret value komt te vervallen, zodat je deze op tijd kunt vernieuwen en delen met Support. De vervaldatum vind je in de kolom Verloopt op:
Instellingen voor meerdere omgevingen
Testomgevingen
Als er meerdere omgevingen zijn die dezelfde database gebruiken, bijvoorbeeld testomgevingen die een backup van productie krijgen, moeten dezelfde SSO-gegevens worden gebruikt voor elk van die omgevingen.
Het nadeel van dezelfde SSO-gegevens is dat bij de portal van de SSO-provider vaak maar één knop gemaakt kan worden om gebruikers door te sturen.
Trainingsomgevingen (of andere losstaande omgevingen)
Omgevingen met een aparte database, bijvoorbeeld een losse omgeving voor trainingen, kunnen gebruik maken van aparte SSO gegevens. Deze omgevingen kunnen dan geen kopie ontvangen van de productie-omgeving.
Gebruikersaccounts
Automatisch koppelen
Automatisch koppelen is mogelijk op basis van medewerkernummer of e-mail.
In het geval van medewerkernummers gaat dit door middel van het veld employee_number, dat moet worden meegestuurd in de meta-informatie. Dit veld moet correct doorgestuurd worden naar Ons SSO. De medewerker moet reeds bestaan in het systeem, bijvoorbeeld door een koppeling met een salarispakket.
Voor meer informatie voor het meesturen van meta-informatie verwijzen we door naar jullie SSO-provider.
E-mail is altijd een onderdeel van een koppeling, koppelen op basis van e-mail werkt daardoor altijd.
Als jullie organisatie ervoor kiest op medewerkernummer te koppelen, worden alle dienstverbanden onder dat medewerkernummer automatisch gekoppeld. Wilt u dit niet, dan moet u het medewerkernummer inclusief het dienstverbandnummer aanleveren. Dit moet dan in de vorm "medewerkernummer-dienstverbandnummer" (bijv 123-1)
Nieuwe gebruikers
Na het aanmelden via SSO wordt er een nieuwe gebruiker aangemaakt, als er nog geen account bestaat voor die medewerker. Als er al wel één of meerdere accounts bestaan, zullen deze automatisch gekoppeld worden op basis van de gekozen strategie.
Nieuwe gebruikers hebben standaard geen rechten, tenzij je dit zo instelt. Dat kan je doen door een 'Standaardrol' aan te maken die basisrechten aan alle gebruikers geeft. Zie ook Ons Autorisatie: automatische rollen beheren.
Wil je inzicht hebben in welke gebruikers al via SSO gekoppeld en ingelogd zijn? Gebruik daarvoor OnsDB. In de tabel 'users' staat een ssoId als de gebruiker gekoppeld is aan de SSO-provider. Als deze leeg is (NULL), dan is de gebruiker nog niet gekoppeld aan de SSO-provider.
SSO ontkoppelen
Het is mogelijk om een gebruiker te ontkoppelen van een SSO-account. Dit kan handig zijn wanneer er een verkeerde koppeling is gemaakt. Dit kan in in het gebruikersscherm, hiervoor is de taak Gebruikers en hun roltoewijzingen bekijken nodig.
Gebruikers zijn te ontkoppelen door naar de medewerker in Ons Administratie te gaan, vervolgens te gaan naar Account en daar onder het kopje Single Sign On te kiezen voor Ontkoppelen.
