Ik ben een Zivver-beheerder
Zivver instellen en beheren
Single Sign-on Setup
Introductie tot Single Sign-On (SSO)
Met Single Sign-On (SSO) kan een gebruiker met één inlognaam en wachtwoord in meerdere applicaties inloggen. De gebruiker hoeft dus niet meerdere wachtwoorden te onthouden. SSO gebruiken is niet alleen gebruiksvriendelijker, maar ook veiliger dan meerdere wachtwoorden gebruiken.
Er bestaan on-premise en cloudoplossingen voor SSO. De bekendste on-premise SSO-oplossing is Microsoft Active Directory Federation Services (ADFS) en is onderdeel van Microsoft Windows Server. De markt verschuift zich echter steeds meer naar cloudoplossingen. Verschillende partijen bieden een SSO-cloudoplossing zoals Microsoft Azure, Google G Suite en Okta. Deze cloudoplossingen bieden naast SSO vaak meerdere functionaliteiten aan.
Voor- en nadelen van een uniek wachtwoord per applicatie
In de basis is het veiliger om per applicatie een zeer sterk wachtwoord te gebruiken. Echter brengt deze methode in de praktijk een aantal nadelen met zich mee:
-
Wachtwoordbeheer per applicatie brengt extra beheerlast met zich mee. Gebruikers vergeten nu eenmaal regelmatig hun wachtwoord. Zeker als een gebruiker per applicatie een apart wachtwoord moet onthouden.
-
Het is complex voor een organisatie om per applicatie een wachtwoordbeleid te voeren, aangezien dit per applicatie moet worden ingesteld en de mogelijkheden voor een wachtwoordbeleid per applicatie kunnen verschillen.
-
Het is lastig of zelfs onmogelijk om te voorkomen dat gebruikers wachtwoorden hergebruiken tussen verschillende applicaties. Dit vermindert het theoretische voordeel van een uniek, sterk wachtwoord per applicatie. Als de gebruiker voor iedere applicatie een wachtwoord moet verzinnen, dan is de kans groot dat deze wachtwoorden sterk op elkaar lijken.
-
Toegang tot de verschillende applicaties is moeilijker te monitoren of te loggen, waardoor gecompromitteerde accounts minder opvallen.
Voordelen gebruik SSO
SSO kan wachtwoordmanagement vereenvoudigen voor zowel de gebruikers als de beheerders:
-
Een gebruiker hoeft maar één wachtwoord te onthouden en kan toch veilig inloggen in meerdere applicaties.
-
Mogelijkheid om accountbeheer centraal te regelen. Dit heeft als voordeel:
-
Minder beheerlast met betrekking tot het resetten van wachtwoorden.
-
Autorisatiebeheer wordt eenvoudiger doordat accountbeheer centraal wordt geregeld en niet per applicatie. Indien een medewerker uit dienst treedt, is met een druk op de knop alle toegang ingetrokken.
-
-
Met Cloud SSO-oplossingen is het heel eenvoudig om accounts extra te beveiligen met een Multi-Factor Authentication (MFA).
-
Cloud SSO-oplossingen bieden vaak een appdashboard. De gebruiker ziet op het dashboard een overzicht van alle beschikbare applicaties. Met één klik start de gebruiker een applicatie op en is dankzij SSO automatisch ingelogd.
-
De meeste Cloud SSO-oplossingen bieden goede monitoring, waardoor een gecompromitteerde account snel gedetecteerd kan worden.
Nadelen gebruik SSO
Het grootste nadeel van SSO gebruiken is dat één ingang (één inlognaam en wachtwoord) toegang geeft tot meerdere applicaties. Als een kwaadwillend persoon/instantie deze inloggegevens in handen krijgt, dan heeft hij daarmee ook overal toegang toe. In theorie zou een Identity Provider (bijvoorbeeld Okta) gegevens kunnen lekken. Echter zal een Identity Provider doorgaans voldoende middelen inzetten om dit te voorkomen. Vaak hebben zij meer middelen ter beschikking om dit te voorkomen dan een gemiddelde IT-afdeling heeft.
Identity Providers (IdP)
SSO werkt op basis van een Identity Provider (IdP) en een Service Provider (SP). De SP kan de gebruiker pas inloggen nadat de IdP de gebruiker authenticeert. Dit laat zien dat er een vetrouwensrelatie tussen de IdP en de SP bestaat. De SP vertrouwt erop dat de IdP de gebruiker goed en veilig authenticeert. Andersom vertrouwt de IdP de SP dat de geauthenticeerde gebruiker en niet een andere gebruiker wordt ingelogd. Een IdP is dus de poortwachter welke de gebruiker authenticeert voor een of meerdere SP’s.
Het gebruik van SSO in Zivver
Als we bovenstaande informatie naar Zivver vertalen, dan betekent dit het volgende: als een organisatie een SSO-koppeling met Zivver opzet, dan neemt de organisatie de verantwoordelijkheid voor het authenticeren van de gebruiker volledig op zich. De IdP geeft namelijk aan Zivver (de SP) aan dat deze specifieke gebruiker in Zivver ingelogd mag worden. De organisatie garandeert daarbij dat de IdP de gebruiker op een veilige manier authenticeert (indien noodzakelijk met een MFA) en dat deze authenticatie niet omzeild kan worden door een kwaadwillend persoon/instantie. Zivver controleert deze SSO-inlogpoging niet en werpt ook geen MFA meer op. Standaard worden alle Zivver-accounts namelijk extra beveiligd met een MFA, tenzij de organisatie deze beveilingslaag uitzet door SSO te gebruiken.
Technische eisen
Zivver kan met iedere IdP een SSO-koppeling opzetten als de IdP SAML 2.0 ondersteunt. Op dit moment hebben wij handleidingen beschikbaar om een SSO-koppeling te maken via de volgende IdP’s.
Okta
Neem contact met ons op via enterprise@zivver.com als jouw organisatie een SSO-koppeling wil opzetten met een IdP waarvoor nog geen handleiding beschikbaar is.
Extern benaderbaar
Niet alle IdP’s zijn extern - buiten het bedrijfsnetwerk - benaderbaar. Een IdP in de cloud is vanzelfsprekend benaderbaar ongeacht de locatie. Om Zivver te gebruiken is het belangrijk dat de IdP extern benaderbaar is. De gebruiker kan waar dan ook (thuis of onderweg) inloggen in de webapp (https://app.zivver.com), de Mobile App (voor Android/iOS) en de OWA add-in. Als de IdP niet extern benaderbaar is, dan kan de gebruiker alleen intern in Zivver inloggen via SSO.
|
Note
|
Gebruikers kunnen alleen intern - binnen het bedrijfsnetwerk - inloggen wanneer de IdP niet extern benaderbaar is. Gebruikers mogen namelijk alleen inloggen via SSO wanneer SSO wordt gebruikt in Zivver. Beheerders kunnen wel extern inloggen met hun Zivver-wachtwoord, want beheerders hebben zowel een Zivver-wachtwoord als SSO-inloggegevens. |