Op deze pagina vind je meer informatie over de mogelijkheden om toegang tot diensten via SURFconext te geven of beperken. Voor de duidelijkheid: de regels waar we het hier over hebben zijn niet bedoeld om te bepalen welke groepen gebruikers überhaupt toegang hebben tot SURFconext. Dit dient in de IdP zelf geconfigureerd te worden!

We behandelen:

Waarom 'autorisatieregels' in SURFconext?

Zoals op 'Beschikbare diensten activeren' genoemd, wil je soms niet dat iedereen van je instelling via SURFconext kan inloggen bij/op een dienst:

• Soms wil je dat alleen een bepaald onderdeel, bijvoorbeeld een bepaalde faculteit, bij een dienst kan (bijvoorbeeld omdat toegang geld/licenties kost)
• Soms is er een reden om alleen studenten of juist alleen docenten bij een dienst toe te laten
• Vaak mogen voorinschrijvers nergens bij, maar bij bepaalde diensten juist wel
• Soms mogen alleen bepaalde mensen die samen in een groep/team zitten bij een dienst

Zonder autorisatieregels krijgt iedere gebruiker van jouw instelling toegang tot een dienst, zodra de koppeling tussen de dienst en jouw Identity Provider geactiveerd is. Het is dan aan de Service Provider om autorisatiefunctionaliteit (wie mag waarbij) in de dienst te bouwen, indien gewenst. Dat kan bijvoorbeeld door in de dienst zelf gebruikers aan te maken en te beheren: alleen gebruikers die bekend zijn kunnen dan de dienst gebruiken (provisioning). Of door te controleren of een gebruiker in een bepaalde groep zit (via een VOOT-koppeling).

Helaas leert de praktijk dat diensten soms geen autorisatiefunctionaliteit willen of kunnen inbouwen, terwijl instellingen wel graag controle willen hebben over de toegang tot een dienst. Het gevolg is dat instellingen dan maar niemand toegang geven.

Met de autorisatieregels krijgen instellingen een extra mogelijkheid om zelf te bepalen wie toegang heeft tot een dienst via SURFconext.

Waar kan ik die regels beheren?

In het SURFconext Dashboard tref je het tabblad 'Autorisatieregels'. SURFconext-verantwoordelijken kunnen daar regels beheren, activeren en deactiveren. In de schermen waarin je regels maakt of wijzigt, tref je ook invul-instructies aan:

Wat voor soort regels kan ik maken?

In het SURFconext Dashboard zijn regels aan te maken die:

• de identiteiten die voldoen aan de opgestelde regels toegang geven tot de dienst (en de rest van de identiteiten dus tegenhouden). Dit heet een 'Permit'-regel
• de identiteiten die voldoen aan de opgestelde regels toegang weigeren tot de dienst (en de rest van de identiteiten dus doorlaten). Dit heet een 'Deny'-regel

We adviseren in hoge mate 'Permit'-regels te definieren. De praktijk wijst uit dat Deny-regels vaak leiden tot onbedoelde effecten en toename van complexiteit in relatie tot andere elementen die toegang beinvloeden.

Een regel is gebaseerd op attributen. Mogelijke attributen zijn:

• Attributen die worden doorgegeven vanuit de instelling:
   
• Lidmaatschap van een groep in SURFconext Teams (https://teams.surfconext.nl) 

AND? OR?

Een van de keuzes die je bij het maken van een regel hebt is of je een AND-regel wil maken of een OR-regel:

• bij een AND-regel moeten alle controles op attributen waar zijn
• bij een OR-regel moet 1 van de controles op attributen waar zijn

Als je met regels aan de slag gaat, kom je mogelijk voor situaties waarin je complexere regels wil maken, van het type "(X OR Y) AND (W OR Z)". Alhoewel de techniek die we gebruiken dat toestaat, hebben we de volgende afweging gemaakt: een zo complexe regel, is ook te maken door hem te splitsen in 2 of meer regels. Het alternatief zou zijn dat we de regel-beheer-interface zo maken dat zulke complexe regels in 1 regel kunnen worden ondergebracht, maar wij denken dat de interface dan zo complex wordt, dat de huidige oplossing (de complexe regel splitsen in meerdere simpele regels) te prefereren is.

Filteren op groepslidmaatschap

Je kunt toegang ook verlenen (of ontzeggen) op basis van lidmaatschap van een groep. Wanneer u een group-provider-koppeling heeft, kunt u ook lokaal bijgehouden groepen, b.v. groepen in de Active Directory, gebruiken om toegang te regelen!

In de huidige versie gaat het gebruik van team-informatie nog wat omslachtig (we onderzoeken of dat makkelijker kan). Dat heeft o.a. te maken met privacy: we willen geen lijst van alle bekende groepen geven die er bestaan in SURFconext Teams. Aan de andere kant moet een SURFconext-verantwoordelijke niet alleen groepen kunnen gebruiken waar hij/zij zelf beheerder of lid van is: mogelijk zitten mensen van zijn instelling in een groep waar de SURFconext-verantwoordelijke geen toegang toe heeft, maar die hij wel kan gebruiken in een regel.

Hoe werkt het dan? Als je wilt filteren op een groepslidmaatschap, gaat degene met toegang tot dat team naar SURFconext Teams. Hij logt in en klikt op de desbetreffende groep. Boven de groep staat een uniek Groeps-ID achter 'Unique ID':

Deze reeks, "urn:collab:group:surfteams.nl:nl:surfnet:diensten:trust_&_ident", dient bekend te zijn bij de SURFconext-verantwoordelijke: die moet die tekenreeks namelijk plakken in een veld bij het aanmaken van een regel. Wanneer de SURFconext-verantwoordelijke geen toegang heeft tot het team, moet iemand met toegang die tekenreeks even opzoeken, kopiëren en naar de SURFconext-verantwoordelijke sturen (bijvoorbeeld via mail).

Zorg je voor een goede foutmelding?

Per regel kun je een 'Deny-melding' invoeren. Stel je voor dat je door een regel wordt tegengehouden om bij een dienst te komen. Dan is het zowel voor jou als gebruiker, maar ook voor mensen die eventueel alsnog toegang moeten geven, goed te weten waarom toegang nu is geweigerd. Vul dus iets in wat informatief is. Bijvoorbeeld: "Alleen medewerkers hebben toegang tot deze dienst.", of "U heeft geen toegang omdat u geen lid bent van de groep XYZ. Meer weten? Neem contact op met helpdesk@instelling.nl." 

Regels aan- en uit zetten, en wat kan ik maximaal fout doen?

Het is belangrijk te beseffen dat:

• Regels veel impact kunnen hebben. Het is mogelijk grote groepen (zelfs iedereen) toegang te geven of juist te ontzeggen.
• Standaard staan regels na het aanmaken uit. Je dient een regel expliciet aan te zetten. Dit kun je doen als laatste stap bij het aanmaken van een regel, of in het overzichtsscherm waarin alle regels staan vermeld. 
• Indien je een regel wijzigt die al aan staat, zal die regel bij het opslaan ook direct aanstaan, tenzij je de regel eerst uit hebt gezet. Twijfel je of een wijziging goed uitpakt, dan kun je er voor kiezen een nieuwe regel te maken, dan de oude uit te zetten en de nieuwe aan te zetten. Zo nodig kun je de oude situatie snel herstellen.

Regels testen

We raden je sterk aan je regels te testen. Hoe grondig je wil testen en op welke manier, hangt af van je regel, en of het bijvoorbeeld om een SP gaat die al door veel mensen gebruikt wordt. Aspecten om te overwegen voor een test:

• Bepaal wie op basis van je regel wel en juist geen toegang meer zou moeten hebben tot een bepaalde dienst. Zorg dat je gebruikers 'bij de hand' hebt die direct na het actief maken van de regel, voor je kunnen testen en kunnen laten weten of de regel lijkt te werken zoals u bedoelde (helaas zijn test-accounts op SURFconext niet toegestaan).
• Overweeg eventueel een regel te testen in de test-omgeving. Dit vergt echter dat je de regel eerst aanmaakt in de test-omgeving, en na de test in de productie-omgeving.
• Test de regel eventueel eerst op een test-SP. Het lijkt een optie dat je daar b.v. profile.surfconext.nl voor gebruikt (bedenk: dit is misschien geen kritische 'dienst', maar wordt wel gebruikt als studenten of medewerkers problemen hebben met inloggen).

Denk er zonodig om je regel(s) uit de test-omgeving te verwijderen (als je bv profile.surfconext.nl gebruikt om te testen).

Wanneer is mijn regel actief?

Tijdens de beta-periode dient elke eerste regel bij een Service Provider handmatig door SURFnet te worden geactiveerd. Dit doen we omdat we in de beta-fase de kans willen verkleinen dat er ongewenste effecten optreden. Echter: zodra er eenmaal een regel is bij een SP, b.v. omdat een andere pilot-instelling een regel bij die SP heeft aangemaakt, zal elke volgende regel voor die SP actief worden, zodra je die regel zelf activeert!

We raden je aan om in het begin, nadat je een regel bij een dienst hebt gedefinieerd, een mail te sturen naar support@surfconext.nl. Meld daarin (je kunt dit copy/pasten in uw mail) "Ik doe mee met de autorisatie-pilot en heb een autorisatieregel aangemaakt voor de dienst <vul_hier_de_naam_van_de_dienst_in>. Willen jullie de regel controleren, en zo nodig activeren en mij laten weten of er opmerkingen zijn, en/of dat de regel geactiveerd is?" (wanneer je in je mail dubbelklikt op "vul_hier_de_naam_van_de_dienst_in" kun je eenvoudig de naam van de dienst invullen).

Als de beta goed verloopt en de functionaliteit in productie wordt genomen, zorgen we dat tussenkomst van SURFnet niet meer nodig is.

Wat zijn de achterliggende technologie en standaarden?

De 'rijke autorisatie'-functie, zoals SURFnet dat noemt, is gebaseerd op de XACML-standaard. Op Wikipedia is meer informatie over XACML beschikbaar. SURFnet heeft kunnen voortbouwen op het werk van OpenAZ, open source gepubliceerde software om XACML-regels af te handelen; dat betekende dat SURFnet minder kosten had en alleen hoefde te zorgen dat de software aansloot op SURFconext, en er een beheer-portal kwam voor het maken van XACML-policies ('toegangs-regels'). SURFnet heeft de door SURF ontwikkelde software open source beschikbaar gesteld in de OpenConext-bibliotheek.