Allereerst, wat is single-sign-on (kortweg SSO) en wat hebben we eraan. Single-sign-on is het maar één keer in hoeven typen van je wachtwoord en op een veilige manier toegang krijgen tot verschillende (externe) systemen. Het intypen van een wachtwoord kan namelijk worden afgekeken, daarom is het beter om dat niet te vaak te hoeven doen.
Voordelen
Wat zijn de voordelen van single-sign-on?
- De gebruiker hoeft maar één wachtwoord te onthouden.
- De gebruiker hoeft maar op één plek zijn wachtwoord in te vullen (en niet op 4 verschillende inlogpagina’s). Je kan gebruikers dus leren dat als het inlogscherm er anders uit ziet dat het waarschijnlijk phishing is.
- Als er een wachtwoord wordt afgekeken (of iemand het post-it blaadje heeft meegenomen) hoeft er maar één account geblokkeerd te worden. Waarschuwing: er zijn gebruikers die overal hetzelfde wachtwoord gebruiken….
- Als beheerder kan je op één plaats instellen of een sterk wachtwoord verplicht is.
- Je kan op één plaats multi-factor-authenticatie implementeren, hierover later meer.
Nadelen
Zijn er dan ook nadelen aan single-sign-on? Eigenlijk is er maar één nadeel, als er een wachtwoord wordt afgekeken heeft de “aanvaller” (lees scholier, hacker of buitenstaander) meteen toegang tot dezelfde systemen als de rechtmatige gebruiker.
Dit nadeel wordt vaak gebruikt als argument om dan maar geen single-sign-on te implementeren.
Hoe werkt het?
Er zijn verschillende manier van single-sign-on maar ze werken allemaal ongeveer hetzelfde.
- De gebruiker gaat naar de website (/applicatie) die hij/zij wil gebruiken.
- De website weet waar het inlogscherm zich moet bevinden.
- De website vraag de gebruiker bij welke organisatie hij/zijn hoort.
- De website stuurt de gebruiker naar het vertrouwde inlogscherm, met een bepaalde code in het url zodat het inlogscherm weet waar de gebruiker naar toe wil.
- Op het inlogscherm zijn er 2 mogelijkheden
- De gebruiker was al ingelogd (op het inlogscherm of een vertrouwde computer).
- De gebruiker was nog niet ingelogd en dient zijn gebruikersnaam en wachtwoord in te typen.
- De gebruiker is nu ingelogd op het inlogscherm van de organisatie (bedrijf of school) en de single-sign-on server van de organisatie stuurt op een veilige manier bepaalde gegevens van de gebruiker naar de (externe) webapplicatie, zodat deze weet welke gebruiker ervan gebruik wil maken. De externe website krijgt op deze manier nooit het wachtwoord van de gebruiker te zien.
Waarom gebruiken we dit (nog) niet?
Single-sign-on is super handig vanuit het punt van de gebruiker, één keer je wachtwoord intypen en meteen overal toegang hebben. Maar waarom gebruikt nog niet iedereen dit?
- Voor het ondersteunen van single-sign-on moet je als organisatie een server inrichten en beheren, Microsoft biedt hier ADFS voor aan, dit zit in de standaard Windows 2012 R2 / Windows 2016 licentie.
- De (externe) website (of applicatie) moet (bij gebruik van ADFS) SAML2, WS-Federation of OpenID-Connect ondersteunen. Bij het uitzoeken/aanbesteden van externe diensten is het verstandig om dit als eis mee te nemen.
- Het argument van de beheerders, als er een wachtwoord wordt afgekeken hebben ze meteen overal toegang.
Dit laatste argument, hoe zorgen we ervoor dat de gevolgen beperkt blijven als er toch een wachtwoord wordt onderschept? Is eenvoudig op te lossen door het inzetten van multi-factor-authenticatie. En dan blijft eigenlijk alleen de wil over om het inloggen voor alle gebruikers daadwerkelijker makkelijker te maken.
Wij kunnen dan ook elke organisatie adviseren om dit te implementeren, het is namelijk erg gebruiksvriendelijk richting je gebruikers. En mocht je deze klus niet zelf kunnen of willen doen, kijk dan eens hier. Wij bieden dit namelijk aan als een van onze diensten.
Single-sign-on implementeren Neem contact op
Multi-factor-authenticatie
Veiligheid is een punt van aandacht bij het implementeren van single-sign-on. Maar hoe zorg je er nu voor dat iemand die het wachtwoord heeft onderschept daar eigenlijk nog maar weinig aan heeft? Multi-factor-authenticatie betekend dat er niet alleen wordt gekeken naar iets dat de gebruiker weet (zijn wachtwoord), maar ook naar iets dat de gebruiker heeft.
Wat kan een gebruiker hebben, waarmee de veiligheid te verbeteren is?
- Een geregistreerd apparaat, bijvoorbeeld een speciale groep computers uit het bedrijfsnetwerk.
- Een speciaal IP-adres, uit een vooraf gedefinieerde range.
- Een hardware token, dit apparaatje genereert elke keer een andere code die moet worden overgetypt op het inlogscherm.
- Een sms code, na het invullen van je gebruikersnaam en wachtwoord ontvang je een sms met een code die je moet invullen op het inlogscherm.
- Een applicatie op je smartphone die vraagt of je op dit moment probeert in te loggen.
- Een applicatie op je smartphone die elke 30 seconden een andere code toont.
Kortom er zijn tal van mogelijkheden die je zou kunnen gebruiken om het inloggen op (bepaalde) applicaties veiliger te maken. De mate van veiligheid van deze mogelijkheden verschilt natuurlijk.
Hier kan je als organisatie zelf een keuze in maken, voor welke applicatie je welke eisen stelt. Heb je een website met het lesrooster, dan mag waarschijnlijk iedereen met een gebruikersnaam en wachtwoord die zien. Maar heb je een applicatie met leerling-dossiers, dan wil je waarschijnlijk een van bovenstaande extra maatregelen nemen.
0 reacties