SURFconext: mogelijkheden om autorisatie in te regelen

Dat SURFconext met behulp van het SAML-protocol zorgt voor authenticatie en daarmee antwoord geeft op de vraag ‘wie is de ingelogde gebruiker’, dat mag als bekend verondersteld worden. Dat het inloggen bij de instelling zelf plaats vindt en dat SURFconext de Single Sign On voor de gebruiker verzorgt, weten de meeste van ons ook. Maar hoe kun je als instelling en dienstaanbieder bepalen wat die ingelogde gebruiker vervolgens mag doen? Dat is stap twee, dat is autorisatie.

De twee voor de hand liggende manieren om door te geven wat een ingelogde gebruiker mag doen zijn (1) doorgeven van (extra) attributen van een gebruiker, waarin een bepaalde eigenschap vastgelegd wordt, bijvoorbeeld ‘gebruiker heeft de rol administrator’. En (2) gebruikers onderverdelen in groepen waarbij het lidmaatschap van een groep de rechten bepaalt, bijvoorbeeld ‘gebruiker is lid van de groep administrators’.

SURFconext biedt de mogelijkheden voor dienstaanbieders om autorisatie toe te passen, maar de dienstaanbieder dient zelf de autorisatie beslissing te implementeren.

SURFconext: attributen

De instelling kan per gebruiker of groep van gebruikers extra attributen toevoegen. Wanneer de gebruiker inlogt bij een dienst worden deze extra SAML attributen meegestuurd en kan de dienst deze uitlezen.

Deze aanpak past binnen de mogelijkheden van de bestaande identity management omgeving van een instelling. De extra attributen kunnen in het (multi-valued) attribuut eduPersonEntitlement worden geplaatst. Een entitlement geeft aan welke rechten de gebruiker heeft binnen de betreffende dienst.

SURFconext filtert attributen per dienst (service provider), zodat alleen maar de attributen die nodig zijn bij de betreffende dienst terecht komen. Welke attributen gedeeld worden met een dienst wordt bepaald door de Attribute Release Policy (ARP). Om goed te kunnen filteren op entitlements, moeten de waarden van dit attribuut een bepaalde syntax hebben, zodat SURFconext de Attribute Release Policy goed kan instellen.

Key Value
urn:mace:dir:attribute-def:eduPersonEntitlement urn:x-surfnet:surf.nl:surfdrive:quota:100

SURFconext kan nu filteren, zodat deze entitlement alleen aan SURFdrive wordt doorgegeven. Voor SURFdrive heeft deze entitlement de betekenis dat de gebruiker recht heeft op een quota van 100gb. De hoeveelheid is hiermee dus gezet door de instelling.

Diagram van groepen en autorisatie daarvan

SURFconext: groepen

Instellingen kunnen (bestaande) groepen gebruikers definiëren via SURFconext Teams en/of via een eigen instelling groupprovider. De dienst kan de groepsinformatie vervolgens raadplegen via de API van SURFconext. Het achterliggende concept is gebruikers te groeperen om vervolgens de groepen her te gebruiken bij meerdere diensten, zonder dat in elke dienst deze groep opnieuw moet worden gedefinieerd. De mutaties van een groep hoeven hierdoor maar op één plaats te worden bijgehouden.

Om als instelling de eigen groepen te gebruiken moet de instelling als group provider optreden richting SURFconext. Hiervoor moet de instellingen zijn LDAP of AD ontsluiten via het VOOT protocol richting SURFconext.

In SURFconext Teams is het mogelijk om als gebruiker zelf een groep te creëren, daar een eigen instellingsgroep aan te koppelen en die uit te breiden met andere/externe gebruikers.

SURFconext kan filteren welke diensten de groepen van een instelling ontvangt. Per dienst geldt dat alle groepslidmaatschappen waar een gebruiker lid van is, worden ontvangen.

Diagram van groepen en autorisatie van attributen

Vergelijking van autorisatie methodes

Welke autorisatie methode moet ik als instelling gebruiken? Hieronder is een overzicht van de voor- en nadelen van beide methoden.

Voordeel Attributen

De afspraken tussen de instelling en de leverancier over de waarde van een attribuut zijn voor (cloud)diensten van de eigen instelling makkelijk te maken. De betreffende attributen (entitlements) zijn verder relatief eenvoudig te beheren in het eigen identity management systeem.

Verder zijn de attributen al bij login van de gebruiker beschikbaar, waardoor de entitlement gebruikt kan worden voor afscherming aan de poort (coarse grained autorisatie).

Nadeel Attributen

Wanneer er veel kleine groepen van gebruikers zijn, die elk een specifieke entitlement nodig hebben voor diensten, dan kan dit extra werk opleveren voor de beheerder van het identity management systeem bij de instelling.

Bij het instellingsoverstijgend samenwerken moet de naamgeving van een attribuut goed afgestemd worden tussen alle partijen, want de beheerders van andere identity management systemen moeten hetzelfde attribuut meegeven.

Voordeel Groepen

Groepen kunnen heel divers zijn. Qua schaalgrootte werken ze zowel bij een klein aantal gebruikers als bij een groot aantal gebruikers per groep. Met gebruik van SURFconext Teams is het tevens mogelijk om gebruikers van andere instellingen te combineren, inclusief externen.

De samenstelling van de groep wordt op één plaats geregeld, waarmee groepen makkelijker her te gebruiken zijn bij meerdere diensten

Het groepslidmaatschap wordt door de applicatie opgevraagd, nadat de gebruiker al toegang heeft gekregen tot de applicatie, wat de mogelijkheid biedt tot afscherming en/of uitdelen van rechten op basis van dit groepslidmaatschap in de applicatie. Het is ook mogelijk om de gegevens op te vragen binnen de applicatie wanneer de gebruiker niet is ingelogd op dat moment.

Nadeel Groepen

Een instelling moet een aparte ‘groupprovider’ creëren (met als bron de LDAP/AD om bestaand groepsverbanden van de eigen instelling te hergebruiken). Alle groepslidmaatschappen zijn per groupprovider en dienstcombinatie zichtbaar voor de dienst. Wanneer een dienst toegang heeft, dan krijgt deze alle groepen van de betreffende provider te zien. Hierbinnen is het wel mogelijk om alleen de groepsnamen weer te geven en niet de leden. Tot slot moet de dienst geschikt zijn om de gegevens bij de SURFconext API op te vragen.

Diagram van groepen en autorisatie vergelijken

Een combinatie van beide methodes is ook mogelijk, waarbij entitlements gebruikt worden voor de toegang aan de poort en groepslidmaatschappen voor rechten in de applicatie.

Een andere mogelijke combinatie is om binnen de SimpleSAMLphp software voor service providers gebruik te maken van de VOOT plugin. Bij login haalt de plugin de groepslidmaatschappen op van de gebruiker en geeft deze samen met zijn attributen van SAML login door aan de applicatie. Dit heeft als voordeel dat de dienst geen aanpassing hoeft te maken om de API op te vragen, maar de groepslidmaatschappen kunnen alleen bij login worden opgevraagd.

Conclusie

In bovenstaand overzicht is aangeven wat de mogelijkheden zijn van SURFconext om autorisatie in te regelen. Welk methode het meest geschikt is om autorisatie af te handelen in een specifiek geval is afhankelijk van een aantal factoren. Het afwegen van de voor- en nadelen biedt hulp bij het maken van een keuze voor autorisatie.

Oproep

SURFnet gaat in 2015 onderzoeken of er meer mogelijkheden zijn voor autorisatie en SURFconext. Wilt u hier als instelling of dienstaanbieder over mee denken? Uw input is zeer welkom! Laat het ons weten!
Neem contact op met: Maarten Kremers via e-mailadres maarten.kremers@surfnet.nl

Blog geschreven door Maarten Kremers en Herman van Dompseler

Auteur

Reacties

Dit artikel heeft 0 reacties