Op deze pagina tref je meer informatie aan over de mogelijkheden om toegang te geven of beperken. 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 via een dienst:

• Soms wil je dat alleen een bepaald onderdeel, b.v. een bepaalde faculteit, bij een dienst kan (b.v. omdat toegang geld/licenties kost)
• Soms is er een reden om alleen studenten, 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

Tot 2016 was het zo dat zodra je een dienst activeerde in je dashboard, dan ook iedereen van je instelling bij die dienst kon. Als dat niet de bedoeling was, moest je gaan zoeken naar een manier om dat te beperken. Soms was dat door in de dienst (SP) zelf gebruikers aan te maken en te beheren: alleen gebruikers die bekend waren kunnen dan de dienst gebruiken. Of door te controleren of iemand in een groep zit (als de dienst een VOOT-koppeling ondersteunt).

Maar soms was het toegankelijk maken van een dienst voor een beperkte groep gebruikers zo lastig, dat instellingen dan maar niemand toegang gaven.

Met 'rijke autorisatie' krijgen instellingen een extra mogelijkheid een dienst via SURFconext toegankelijk te maken voor een beperkte groep gebruikers. 

Waar kan ik die regels beheren?

In het SURFconext dashboard tref je het tabblad 'Access policies'. Wanneer je de juiste autorisatie hebt kun je daar regels beheren, activeren en de-activeren. In de schermen waarin je regels maakt of wijzigt, tref je ook invul-instructies aan: 

Wat voor soort regels kan ik maken?

De standaard waarop deze functionaliteit is gebaseerd is erg flexibel. Het 'bedienen'/beheren kan dan ook erg complex worden. SURFnet heeft gekozen om te starten met een relatief simpele set mogelijkheden, omdat we inschatten dat die aansluit op behoeftes van instellingen. Indien we horen dat er behoefte is aan meer, dan gaan we kijken of dat te realiseren is.

In het huidige beheerscherm 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 'Allow'-regel
• de identiteiten die voldoen aan de opgestelde regels toegang weigeren tot de dienst (en de rest van de identiteiten dus door laten). Dit heet een 'Deny'-regel

Een regel is gebaseerd op attributen. Mogelijke attributen:

• een aantal (zie de dropdown in het regel-maak-scherm) attributen die worden doorgegeven vanuit de instelling:
   
• lidmaatschap van een groep in SURFconext teams

De architectuur van de oplossing maakt het mogelijk relatief eenvoudig extra attributen (zie hier welke attributen SURFconext kent) of bronnen toe te voegen waarop regels gebaseerd kunnen worden. 

AND? OR?

1 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) AND". 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

Het toegang verlenen (of ontkennen) op basis van lidmaatschap van een groep gaat in de huidige versie omslachtig. 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 beheerder niet alleen groepen kunnen gebruiken waar hij/zij zelf beheerder of lid van is: mogelijk zitten mensen van zijn/haar instelling in een groep waar de 'regel-beheerder' geen toegang toe heeft, maar die hij/zij wel kan gebruiken in een regel.

Hoe werkt het dan? Als je wil filteren op een groepslidmaatschap, gaat degene met toegang tot dat team naar SURFconext teams. Hij/zij logt in, en klikt op de groep. Boven de groep staat een uniek groepsid achter 'Unique ID:':

Deze reeks, "urn:collab:group:surfteams.nl:nl:surfnet:diensten:trust_&_iden", dient bekend te zijn bij de regel-beheerder: die moet die tekenreeks namelijk plakken in een veld bij het aanmaken van een regel. Wanneer de beheerder geen toegang heeft tot het team, moet iemand met toegang die tekenreeks even opzoeken, kopieren en naar de regelbeheerder sturen (b.v. 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, en ook iets wat informatief is. Bijvoorbeeld: "U heeft geen toegang omdat u geen lid bent van de groep XYZ. Meer weten? Neemtcontact 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 ontnemen.
• 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 aan staan, 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.

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.