Neemt je instelling SURFsecureID af? Dan kun je natuurlijk SURFsecureID gebruiken met alle diensten die je via SURFconext gekoppeld hebt.
Deze pagina beschrijft hoe je, als je SURFsecureID afneemt en hebt ingericht, dit kunt inschakelen voor op SURFconext aangesloten diensten (Service Providers / SP's). De configuratie en aanroep vindt plaats binnen SURFconext. Je hoeft je identity provider hiervoor dus niet aan te passen. Service providers hoeven ook geen aanpassingen te maken, behalve bij optie 3.
De SURFsecureID-integratie kan overigens vrijelijk gecombineerd worden met alle andere functionaliteit van SURFconext, zoals Autorisatieregels, OpenID Connect, eduGAIN, IdP-initiated login, etc. Ook kunnen de verschillende methoden voor SURFsecureID naast elkaar gebruikt worden - mochten meerdere van toepassing zijn op een inlog, dan geldt het hoogste Level of Assurance.
In alle gevallen wordt het behaalde level of assurance ook naar de Service Provider doorgegeven in het AuthnContextClassRef-element van de SAML-assertion, of acr bij OpenID Connect.
1. SURFsecureID voor al je gebruikers van een SP
Je kunt voor elke Service Provider die je gekoppeld hebt ervoor kiezen om SURFsecureID in te schakelen op deze koppeling. Elke gebruiker van jouw instelling die wil inloggen op deze dienst(en) moet dan een geldig token kunnen tonen met het mininmale Level of Assurance dat je opgeeft. Gebruikers van jouw instelling zonder zo'n token kunnen niet inloggen en zullen van SURFconext een melding krijgen.
Deze optie is het eenvoudigst, het overzichtelijkst en (daarom) ook het veiligst: van iedere inlog op de SP is gegarandeerd dat die met een SURFsecureID-geverifieerd token is gedaan.
Je kunt dit instellen via het SURFconext IdP Dashboard. De SURFconext-verantwoordelijke kan daar de betreffende dienst opzoeken, klikken op het tabje "SURFsecureID" en daar het gewenste minimum Level of Assurance (2 danwel 3) opgeven.
2. SURFsecureID inschakelen op basis van de gebruikerscontext
Als je graag SURFsecureID wilt inzetten voor een bepaalde Service Provider maar niet in alle gevallen, kunnen onze context-gebaseerde policy's van dienst zijn. Je kunt er dan voor kiezen om op basis van criteria te bepalen wanneer er een token (en van welk minimum Level of Assurance) getoond moet worden tijdens het inloggen.
De criteria worden gedefinieerd middels de attributen van de gebruiker. Zo kun je ervoor kiezen om eduPersonAffiliation ("medewerker" of "student") te gebruiken, of entitlements. Elk attribuut dat je Identity Provider over de gebruiker levert kan gebruikt worden, ongeacht of dit attribuut ook aan de SP verstrekt wordt. Een andere populaire optie is lidmaatschap van een SURFconext Invite-rol (v/h SURFconext Teams), waarbij de leden van de rol een andere policy krijgen dan de overige gebruikers. Ook kan er geschakeld worden op basis van het IP-adres van de gebruiker, en bijvoorbeeld een token vereist worden tenzij de gebruiker zich binnen een bepaalde IP-range bevindt. Meerdere regels tegelijk actief hebben is mogelijk.
Als een gebruiker voldoet aan de criteria waarvoor een LoA is vereist, zal die om een token gevraagd worden en ook moeten tonen. Andere gebruikers kunnen gewoon verder zonder om een token gevraagd te worden.
Regels worden door het SURFconext-team geconfigureerd. Het kan door de SURFconextverantwoordelijke aangevraagd worden via support@surfconext.nl. Via het SURFconext Dashboard is onder Autorisatieregels wel zichtbaar voor de instelling welke regels zijn geconfigureerd.
3. Dynamisch in de applicatie een SURFsecureID LoA vereisen
Naast het vereisen voor alle gebruikers, of een bepaald deel ervan, bij de initiële inlog, is het ook mogelijk dat de Service Provider zelf signaleert dat er in een bepaald geval nu een 'step up' tot een bepaald Level of Assurance nodig is. Alle gebruikers loggen in principe in via SURFconext met alleen hun eerste factor (de eigen IdP). Op het moment dat de applicatie signaleert dat nu meer zekerheid nodig is, doet zij een nieuwe aanroep naar SURFconext met een verzoek om een minimum Level of Assurance. Een voorbeeld kan zijn een cijferapplicatie waarop iedereen kan inloggen om de cijfers te bekijken, maar dat zodra cijfers ingevoerd gaan worden, de applicatie eerst via SURFconext het presenteren van een token vereist.
De Service Provider zal hierop dus moeten zijn aangepast, zodat die op het betreffende punt in de applicatie die aanroep kan uitvoeren. De SP vraagt dan aan SURFconext in het AuthnRequest (kan zowel in SAML 2.0 als met OpenID Connect) om een bepaald minimum Level of Assurance. Omdat er meestal sprake is van Single Sign On, zal de gebruiker op dat moment niet opnieuw met gebruikersnaam en wachtwoord hoeven in te loggen (die had ze al ingegeven bij de eerste login op de dienst), maar wel haar token moeten presenteren van minimaal dit level. In de assertion terug naar de service provider wordt aangegeven dat dit Level of Assurance inderdaad geverifieerd is, waarna ze (bijvoorbeeld) de cijfers kan goedkeuren.
Technische documentatie over het format van het authenticatierequests voor Service Provider staat hier: Requesting SURFsecureID in authentication requests.
Hier hoeft geen configuratie voor aangepast te worden of een aanvraag voor te gebeuren. Elke op SURFconext aangesloten service provider kan als die dat wil dit verzoek sturen waarna het door SURFconext wordt afgehandeld. Uiteraard dient de betrokken Identity Provider wel SURFsecureID af te nemen, anders kan een gebruiker per definitie geen token tonen.
Vragen?
Deze documenatie behandelt specifiek de integratie van SURFsecureID met aan SURFconext gekoppelde diensten.
Meer informatie over SURFsecureID in het algemeen, hoe dit af te nemen, tokens en levels of assurance vind je op SURFsecureID.
Het SURFconext-team is altijd beschikbaar op support@surfconext.nl voor vragen over deze of andere functionaliteit van SURFconext.