Meerdere keren inloggen op een dag werkt verstorend voor medewerkers. Fortes Change Cloud ondersteunt Single Sign-On. Met Single Sign-On (SSO) loggen medewerkers eenmalig in om toegang te krijgen tot de systemen die ze nodig hebben. Hiermee wordt de beveiliging en het gebruikersgemak verhoogd.
Ook kun je binnen Fortes Change Cloud gebruik maken van automatische gebruiker synchronisatie om het beheer van omvangrijke en/of ingewikkelde processen te vergemakkelijken.
Het toekennen van rechten in Fortes Change Cloud blijf je regelen in de applicatie, zodat de juiste rechten kunnen worden verleend.
Hoe werkt Single Sign-On (SSO)
SSO is gebaseerd op het concept van federatieve identiteit. Dat houdt in dat attributen worden gedeeld met vertrouwde systemen.
Als een gebruiker door het ene systeem wordt vertrouwd, wordt aan hem of haar ook automatisch toegang verleend tot alle andere systemen die een vertrouwde relatie met het eerste systeem hebben. Dit concept vormt de basis voor moderne SSO-oplossingen die worden ondersteund door protocollen zoals OpenID Connect en SAML 2.0.
Bij een aanmelding wordt een authenticatietoken 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 typen providers: service providers (SP) en identity providers (IdP).
- Serviceproviders (SP) zijn de systemen en toepassingen die gebruikers gedurende de dag gebruiken.
- Een identity provider (IdP) is het systeem dat gebruikersverificatie uitvoert. Dit is de centrale locatie waar inloggegevens daadwerkelijk worden opgeslagen en gevalideerd worden.
De voordelen
Een organisatie die de best practices voor SSO volgt, kan met een betrouwbare SSO-oplossing de beveiliging verbeteren. De volgende punten zijn de belangrijke voordelen van Single Sign-On:
- Minder aanvalsmogelijkheden: SSO maakt een einde een slechte wachtwoordhygiëne, waardoor uw organisatie onmiddellijk minder kwetsbaar is voor phishingaanvallen. Met SSO hoeven gebruikers maar één sterk, uniek wachtwoord te onthouden en hoeven er veel minder tijdrovende en dure resets van wachtwoorden te worden uitgevoerd.
- Naadloze en veilige gebruikerstoegang: SSO biedt in real time inzicht in welke gebruikers op welk moment en vanaf welke locatie applicaties gebruiken. Zo kunnen organisaties de integriteit van hun systemen optimaal beschermen. SSO-oplossingen houden ook rekening met andere beveiligingsrisico’s, zoals een werknemer die het device van de organisatie kwijtraakt. IT-teams kunnen in zo’n geval onmiddellijk de toegang van het device tot accounts en cruciale data uitschakelen.
- Eenvoudigere controle van gebruikerstoegang: het kan lastig zijn om de juiste mensen het juiste toegangsniveau tot gevoelige data en resources te bieden in een zakelijke omgeving die voortdurend verandert. SSO-oplossingen kunnen worden gebruikt om de toegangsrechten van een gebruiker te configureren op basis van functie, afdeling of senioriteit. Op deze manier is de transparantie en het inzicht in de verschillende toegangsniveaus altijd gewaarborgd.
- Zelfstandige en productieve gebruikers: gebruikers vragen steeds vaker om snelle en naadloze toegang tot de applicaties die ze nodig hebben om hun werk te doen. Het handmatig beheren van dit soort verzoeken is een tijdrovend proces dat alleen maar frustratie oproept. SSO-authenticatie maakt handmatig toezicht overbodig en biedt met een simpele muisklik direct toegang tot duizenden apps.
- 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 voor beveiliging implementeren, zoals Two Factor Authentication (2FA).
Risico
Het risico van Single Sign-On is dat wanneer je eenmaal ingelogd bent je overal toegang toe hebt. Het wordt daarom sterk aanbevolen om elke SSO-oplossing te combineren met een extra niveau van authenticatie (Two Factor Authentication).
SSO en Two Factor Authentication
Eenmalige toegang moet natuurlijk veilig zijn. Voor het inloggen in Fortes Change Cloud is Two-Factor Authentication (2FA) aan te raden, daardoor is elke gekoppelde applicatie ook met 2FA afgeschermd. De identiteity provider stelt deze functionaliteit beschikbaar voor gebruikers. Op deze wijze vormt 2FA een extra beveiligingslaag in je landschap.
Inregelen Single Sign On voor Fortes Change Cloud
Single Sign-On te gebruiken is het belangrijk dat de identity provider met Fortes Change Cloud kan communiceren. Het instellen van een identity provider dient zowel in Fortes Change Cloud als bij de identity provider zelf gedaan te worden.
Door in het systeem van de identity provider een ‘’vertrouwde applicatie’’ toe te voegen weet de identity provider dat deze applicatie gebruikt mag worden door de medewerkers binnen de organisatie. Fortes Change Cloud dient daarom eerst geregistreerd te worden bij de desbetreffende 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 gebruik maken van SAML kunnen worden gebruikt om een koppeling te maken met Fortes Change Cloud. Voorbeelden zijn: ADFS, OKTA, Azure, SURFconext, Shibboleth, OpenAM/OpenSSO, GlobalSign, etc..
- Shibboleth (ook SP):
Het Shibboleth-project is een implementatie van SAML. Shibboleth is een identity provider die OpenSAML gebruikt om de SAML-functionaliteit te leveren.
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 het registreren wordt door de identity provider vaak gevraagd om een aantal gegevens.
- Naam: de naam van de desbetreffende applicatie
- Domein: het (sub)domein waar de applicatie op draait
- Redirect URI: de locatie binnen Fortes Change Cloud waar de gebruiker naartoe wordt gestuurd als hij is ingelogd bij de identity provider. Vb. https: //mijnbedrijf.fortes-online.com
Note! De service provider heeft van de identity provider een metadata file of de federatie URL nodig. Neem hiervoor contact op met support@fortes.nl
Aanmaken en migreren van (bestaande) gebruikers
In Fortes Change Cloud wordt de mogelijkheid gegeven om het aanmaken van nieuwe gebruikers en de migratie van bestaande gebruikers in te stellen.
Hiervoor bestaan twee instellingen:
- Handmatig gebruikers aanmaken/bijwerken:
Wanneer er gebruik wordt gemaakt van Single Sign-On wordt de match gedaan op een unieke identifier.
Aan de kant van de identity provider en de service provider dient de gebruiker identiek te zijn. Je kunt er voor kiezen om de gebruikersgegevens zelf handmatig in te voeren in de gebruikersbeheer of eens in de zoveel tijd te importeren als resources om ze daarna in Fortes vervolgens te upgraden naar resources met een gebruikersnaam. Gebruik hiervoor een importtaak
- Automatisch nieuwe gebruikers aanmaken/bijwerken:
Ook is het mogelijk om automatisch nieuwe gebruikers aan te maken of bestaande gebruikers bij te werken. Als deze instelling aan staat kan de beheerder bij de identity provider gebruikers markeren om gebruik te maken van Single Sign On in combinatie met de automatische gebruikers synchronisatie. Dit gaat via het SCIM protocol.
Wat is SCIM
SCIM, ofwel System for Cross-domain Identity Management, is een open standaard voor geautomatiseerde gebruikersynchronisatie van gebruikers.
SCIM communiceert gegevens van gebruikers tussen identity providers en serviceprovider die informatie over gebruikersidentity’s vereisen.
De client is meestal een identity provider (IdP), zoals Okta of Azure die een active directory met gebruikersgegevens bevat. Een serviceprovider (SP) is doorgaans een SaaS-app zoals Fortes Change Cloud.
Waarom SCIM gebruiken?
In het kort komt het er op neer dat SCIM gegevens van gebruikers veiliger maakt en de gebruikerservaring vereenvoudigt door een bestaand proces te automatiseren.
Naarmate organisaties groeien neemt meestal ook het aantal gebruikers exponentieel toe. Alle verzoeken om gebruikers toe te voegen en te verwijderen, machtigingen te wijzigen en nieuwe typen accounts toe te voegen vergen kostbare IT-tijd.
Met SCIM kunnen gebruikersgegevens rechtstreeks bij een identity provider (OKTA, Azure, etc..) worden gemaakt of worden geïmporteerd uit externe systemen zoals HR-software of Active Directory. Daarnaast wordt de kans op fouten drastisch verminderd.
IT-afdelingen hoeven geen aangepaste integraties meer te ontwikkelen en voortdurend te updaten om directory’s te verbinden met verschillende externe tools en apps.
Omdat het een standaard betreft, heeft het als bijkomend voordeel dat de gegevens van gebruikers op een consistente manier worden opgeslagen. Hierdoor kunnen IT-afdelingen het bestaande proces automatiseren terwijl ze ook nog eens vanuit één systeem toestemmingen en groepen kunnen beheren.
Zo werkt de SCIM implementatie
Zowel aan de kant van de identity provider (Okta, Azure, etc..) als aan de kant van de serviceprovider (Fortes Change Cloud) moeten zaken worden geconfigureerd.
- Activeer SCIM (SP):
vanaf versie 12.1 van Fortes Change Cloud is het (op verzoek) mogelijk om SCIM te gebruiken voor gebruikerssynchronisatie. Hiervoor moet Fortes een specifieke module inschakelen. Hier zijn verder geen kosten aan verbonden. Neem hiervoor contact op met support@fortes.nl. Wanneer SCIM ingeschakeld is vind je de instelling onder het configuratiemenu in Fortes Change Cloud. Op deze pagina zijn de tokens beschikbaar die je kunt gebruiken om de koppeling tot stand te brengen.
De primary en secondary token is een geautomatiseerde unieke token dat voor iedere klant anders is. Mocht je de primary token in gebruik hebben of besluiten om een ander systeem met SCIM te gebruiken kan hiervoor de secondary token worden gebruikt. Wil je beide tokens vernieuwen dan kan dit met de knop “Ververs token”.
- Maak een test opzet (IDP):
Zorg ervoor dat je de koppeling eerst test in een test-opstelling. Je kunt er bijvoorbeeld voor kiezen om een test identity provider te gebruiken of te testen met één gebruiker. Zo verlaag je het risico dat er in de productie iets fout gaat.
- Configureer SCIM (IDP) (Okta, Azure, etc..):
Omdat per provider de handelingen anders zijn volgt hieronder 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
- Synchroniseer gebruikersgegevens naar Fortes:
Wanneer aan de identity provider kant gegevens worden gewijzigd, zoals voornaam, mailadres of gebruikersnaam, worden deze gegevens automatisch met Fortes gesynchroniseerd.
De identity provider kan ook gegevens vanuit Fortes lezen en onjuiste waarden corrigeren. Het is daarom van belang om na te gaan welk uniek veld hiervoor gebruikt zal gaan worden. Meestal is dit de gebruikersnaam of het mailadres.
Bij in- en uitdiensttreding van medewerkers wordt de gebruiker in Fortes tevens beïnvloed. Bij indiensttreding wordt een gebruiker in Fortes aangemaakt of geactiveerd en bij uitdiensttreding gearchiveerd. Het is goed om te weten dat gegevens niet verloren gaan bij uitdiensttreding en dat medewerker die weer terugkomen weer actief gemaakt kunnen worden in Fortes zonder historische gegevens kwijt te raken.
