Meerdere aanmeldingen op een dag zijn storend voor medewerkers. Fortes Change Cloud ondersteunt Single Sign-On. Met Single Sign-On (SSO) loggen medewerkers één keer in om toegang te krijgen tot de systemen die ze nodig hebben. Dit verhoogt de veiligheid en het gebruiksgemak.
Je kunt ook gebruik maken van automatische gebruikerssynchronisatie binnen Fortes Change Cloud om het beheer van uitgebreide en/of complexe processen te vergemakkelijken.
Het toewijzen van rechten in Fortes Change Cloud blijft in de applicatie, zodat de juiste rechten kunnen worden toegekend.
Hoe werkt Single Sign-On (SSO)?
SSO is gebaseerd op het concept van federatieve identiteit. Dit betekent dat attributen worden gedeeld met vertrouwde systemen.
Als een gebruiker vertrouwd wordt door één systeem, krijgt hij of zij ook automatisch toegang tot alle andere systemen die een vertrouwensrelatie hebben met het eerste systeem. Dit concept vormt de basis voor moderne SSO-oplossingen die worden ondersteund door protocollen zoals OpenID Connect en SAML 2.0.
Wanneer een gebruiker inlogt, wordt een authenticatie-token aangemaakt en opgeslagen in de browser van de gebruiker of op de server van de SSO-oplossing. Elke app of website die vervolgens door de gebruiker wordt geopend, raadpleegt de SSO-service die vervolgens het token van de gebruiker doorstuurt om de identiteit vast te stellen en toegang te verlenen. Er zijn twee soorten providers: service providers (SP) en identity providers (IdP).
- Service providers (SP) zijn de systemen en applicaties die gebruikers de hele dag door gebruiken.
- Een identity provider (IdP) is het systeem dat de authenticatie van gebruikers uitvoert. Dit is de centrale locatie waar inloggegevens worden opgeslagen en gevalideerd.
De voordelen:
Een organisatie die de best practices van SSO volgt, kan de beveiliging verbeteren met een betrouwbare SSO-oplossing. Hieronder volgen de belangrijke voordelen van Single Sign-On:
- Minder aanvalskansen: SSO elimineert slechte wachtwoordhygiëne, waardoor uw organisatie onmiddellijk minder kwetsbaar wordt voor phishing-aanvallen. Met SSO hoeven gebruikers maar één sterk, uniek wachtwoord te onthouden en hoeven ze veel minder tijdrovende en dure wachtwoorden opnieuw in te stellen.
- Naadloze en veilige gebruikerstoegang: SSO biedt realtime inzicht in welke gebruikers applicaties op welk moment en vanaf welke locatie gebruiken. Hierdoor kunnen organisaties de integriteit van hun systemen optimaal beschermen. SSO-oplossingen houden ook rekening met andere beveiligingsrisico’s, zoals een medewerker die het apparaat van de organisatie kwijtraakt. IT-teams kunnen in zo’n geval onmiddellijk de toegang van het apparaat tot accounts en kritieke gegevens uitschakelen.
- Eenvoudigere controle over gebruikerstoegang: het kan moeilijk zijn om de juiste mensen het juiste toegangsniveau te geven tot gevoelige gegevens en bronnen in een bedrijfsomgeving die voortdurend verandert. SSO-oplossingen kunnen worden gebruikt om de toegangsrechten van een gebruiker te configureren op basis van functietitel, afdeling of anciënniteit. Op deze manier is transparantie en inzicht in de verschillende toegangsniveaus altijd gegarandeerd.
- Onafhankelijke en productieve gebruikers: gebruikers eisen steeds vaker snelle en naadloze toegang tot de applicaties die ze nodig hebben om hun werk te doen. Het handmatig beheren van dit soort aanvragen is een tijdrovend proces dat alleen maar voor frustratie zorgt. SSO-authenticatie maakt handmatig toezicht overbodig en biedt met één muisklik direct toegang tot duizenden applicaties.
- Toekomstbestendig: SSO is de eerste stap in het beveiligen van uw organisatie en uw gebruikers. Met SSO als basis kunnen organisaties ook andere best practices op het gebied van beveiliging implementeren, zoals Two Factor Authentication (2FA).
Risico:
Het risico van Single Sign-On is dat je overal bij kunt als je eenmaal bent ingelogd. Het wordt daarom sterk aangeraden om elke SSO-oplossing te combineren met een aanvullend authenticatieniveau (Two Factor Authentication).
SSO en Two Factor Authentication:
Eenmalige toegang moet natuurlijk veilig zijn. Voor het inloggen op Fortes Change Cloud wordt Two-Factor Authenticatie (2FA) aanbevolen, waarbij elke gekoppelde applicatie ook wordt beveiligd met 2FA. De identity provider stelt deze functionaliteit beschikbaar aan gebruikers. Op deze manier voegt 2FA een extra beveiligingslaag toe aan uw landschap.
Single Sign On instellen voor Fortes Change Cloud
Om Single Sign On te kunnen gebruiken, is het belangrijk dat de identity provider kan communiceren met Fortes Change Cloud. Het instellen van een identity provider moet zowel in Fortes Change Cloud als bij de identity provider zelf gebeuren.
Door een ”vertrouwde applicatie” toe te voegen aan het systeem van de identity provider, weet de identity provider dat deze applicatie gebruikt mag worden door medewerkers binnen de organisatie. Fortes Change Cloud moet daarom eerst worden geregistreerd bij de betreffende identity provider. Fortes Change Cloud ondersteunt de volgende protocollen:
- Security Assertion Markup Language (SAML):
SAML staat voor Security Assertion Markup Language en is een van de meest gebruikte standaarden voor het uitwisselen van authenticatiegegevens. Alle producten die SAML gebruiken kunnen worden gebruikt om te interfacen met Fortes Change Cloud. Voorbeelden zijn: ADFS, OKTA, Azure, SURFconext, Shibboleth, OpenAM/OpenSSO, GlobalSign, etc.. - Shibboleth (ook wel SP genoemd):
Het Shibboleth-project is een implementatie van SAML. Shibboleth is een identity provider die OpenSAML gebruikt om SAML functionaliteit te bieden.
Voorbeelden van SSO-documentatie (identity provider):
- ADFS: https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services
- OKTA: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Overview_of_Managing_Apps_and_SSO.htm
- Azure: https://docs.microsoft.com/nl-nl/azure/active-directory/saas-apps/fortes-change-cloud-tutorial
- SURFconext: https://wiki.surfnet.nl/display/surfconextdev/SAML+Basics
Na registratie vraagt de identiteitsprovider vaak om een aantal gegevens.
- Naam: de naam van de applicatie in kwestie
- Domein: het (sub)domein waarop de applicatie draait
- Redirect URI: de locatie binnen Fortes Change Cloud waar de gebruiker naartoe wordt gestuurd als hij is ingelogd bij de identity provider. Voorbeeld: https: //mijnbedrijf.fortes-online.com
Opmerking! De serviceprovider heeft een metadatabestand of de federatie-URL van de identity provider nodig. Neem hiervoor contact op met support@fortes.nl.
Aanmaken en migreren van (bestaande) gebruikers:
In Fortes Change Cloud kan het aanmaken van nieuwe gebruikers en het migreren van bestaande gebruikers worden ingesteld.
Hiervoor bestaan twee instellingen:
- Handmatig gebruikers aanmaken/bijwerken:
Als Single Sign-On wordt gebruikt, wordt de match gemaakt op basis van een unieke identifier.
Aan de kant van de identity provider en de service provider moet de gebruiker identiek zijn. Je kunt ervoor kiezen om de gebruikersgegevens handmatig in te voeren in de gebruikersmanager of om ze af en toe te importeren als resources en ze dan in Fortes op te waarderen naar resources met een gebruikersnaam. Gebruik hiervoor een importtaak
- Automatisch nieuwe gebruikers aanmaken/bijwerken:
Het is ook mogelijk om automatisch nieuwe gebruikers aan te maken of bestaande gebruikers bij te werken. Als deze instelling is ingeschakeld, kan de beheerder bij de identity provider gebruikers markeren om Single Sign On te gebruiken in combinatie met automatische gebruikerssynchronisatie. Dit gebeurt via het SCIM-protocol.
Wat is SCIM?
SCIM, of System for Cross-domain Identity Management, is een open standaard voor geautomatiseerde synchronisatie van gebruikers.
SCIM communiceert gebruikersgegevens tussen identiteitsproviders en serviceproviders die identiteitsgegevens van gebruikers nodig hebben.
De client is meestal een identity provider (IdP), zoals Okta of Azure, die een actieve directory met gebruikersgegevens bevat. Een service provider (SP) is meestal een SaaS-app zoals Fortes Change Cloud.
Waarom SCIM gebruiken?
In een notendop maakt SCIM gebruikersgegevens veiliger en vereenvoudigt het de gebruikerservaring door een bestaand proces te automatiseren.
Als organisaties groeien, neemt het aantal gebruikers meestal exponentieel toe. Alle verzoeken om gebruikers toe te voegen en te verwijderen, machtigingen te wijzigen en nieuwe soorten accounts toe te voegen, verbruiken kostbare IT-tijd.
Met SCIM kunnen gebruikersgegevens direct worden aangemaakt bij een identity provider (OKTA, Azure, etc..) of worden geïmporteerd uit externe systemen zoals HR-software of Active Directory. Daarnaast wordt de kans op fouten drastisch verminderd.
IT-afdelingen hoeven niet langer aangepaste integraties te ontwikkelen en voortdurend bij te werken om directories te verbinden met verschillende externe tools en apps.
Omdat het een standaard is, heeft het als bijkomend voordeel dat gebruikersgegevens op een consistente manier worden opgeslagen. Hierdoor kunnen IT-afdelingen het bestaande proces automatiseren en tegelijkertijd machtigingen en groepen beheren vanuit één systeem.
Zo werkt de implementatie van SCIM.
Zowel aan de kant van de identity provider (Okta, Azure, etc..) als aan de kant van de service provider (Fortes Change Cloud) moeten dingen worden geconfigureerd.
- SCIM inschakelen (SP):
Vanaf versie 12.1 van Fortes Change Cloud is het (op aanvraag) mogelijk om SCIM te gebruiken voor gebruikerssynchronisatie. Hiervoor moet Fortes een specifieke module inschakelen. Hier zijn geen verdere kosten aan verbonden. Neem contact op met support@fortes.nl voor meer informatie. Wanneer SCIM is ingeschakeld vind je de instelling onder het configuratiemenu in Fortes Change Cloud. Op deze pagina vind je de tokens die je kunt gebruiken om de koppeling tot stand te brengen.
Het primaire en secundaire token is een geautomatiseerd uniek token dat voor elke klant anders is. Als u het primaire token gebruikt of besluit om een ander systeem met SCIM te gebruiken, kunt u het secundaire token gebruiken. Als u beide tokens wilt vernieuwen, kunt u de knop “Vernieuw token” gebruiken.
- Maak een testopstelling (IDP):
Zorg ervoor dat je de koppeling eerst test in een testopstelling. Je kunt er bijvoorbeeld voor kiezen om een test identity provider te gebruiken of te testen met één gebruiker. Zo verklein je het risico dat er in productie iets fout gaat. - SCIM (IDP) configureren (Okta, Azure, enz..):
Omdat de werking van elke provider anders is, volgt hier documentatie van de meest gebruikte identity providers:- Azure: https://docs.microsoft.com/nl-nl/azure/active-directory/saas-apps/fortes-change-cloud-provisioning-tutorial
- OKTA: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard_SCIM.htm
- Amazon AWS: https://docs.aws.amazon.com/singlesignon/latest/userguide/scim-profile-saml.html
- OneLogin: https://developers.onelogin.com/scim
- Gebruikersgegevens synchroniseren met Fortes:
Wanneer gegevens worden gewijzigd aan de kant van de identity provider, zoals voornaam, e-mailadres of gebruikersnaam, worden deze gegevens automatisch gesynchroniseerd met Fortes.
De identity provider kan ook gegevens uit Fortes lezen en onjuiste waarden corrigeren. Het is daarom belangrijk om te controleren welk uniek veld hiervoor gebruikt gaat worden. Meestal is dit de gebruikersnaam of het e-mailadres.
Wanneer medewerkers het bedrijf binnenkomen en verlaten, heeft dit ook gevolgen voor de gebruiker in Fortes. Wanneer een medewerker het bedrijf binnenkomt, wordt een gebruiker aangemaakt of geactiveerd in Fortes en wanneer hij of zij het bedrijf verlaat, wordt de gebruiker gearchiveerd. Het is goed om te weten dat gegevens niet verloren gaan bij het verlaten van het bedrijf en dat medewerkers die terugkeren weer actief kunnen worden gemaakt in Fortes zonder historische gegevens te verliezen.
