Via deze nieuwsbrief houden we je op de hoogte van het laatste nieuws rondom SURFconext. Hierbij moet je denken aan nieuwe releases van het platform, best practices, recent aangesloten diensten, interessante bijeenkomsten en plannen voor de toekomst.

Je ontvangt deze nieuwsbrief omdat je SURFconext-verantwoordelijke of -beheerder bent, of lid bent van de SURFconext-alertlijst.

In dit nummer:

1. Nog minder dan 2 weken: de SURFconext Identity & Access Unconference
2. Vraag van de maand van het IAM-forum (vvdmIAMf)
3. IAM-specialisten onder elkaar: drie vragen aan...
4. Attribuut van de maand: mail
5. Afscheid van het CXT-ticket
6. Nieuwe diensten

Nog minder dan 2 weken: de SURFconext Identity & Access Unconference

Op dinsdag 28 oktober houden we de tweede SURFconext Identity & Access Unconference. Met meer dan honderd deelnemers zijn we enorm vereerd, en met zoveel mensen wordt het vast en zeker een interessante dag.

Als je er vorig jaar bij was ken je het concept unconference al: niet de hele dag lekker in je stoel zitten en luisteren naar presentaties, maar actief aan de slag met onderwerpen die je zelf aan mag dragen. Je krijgt dus een uitgelezen kans om met collega's van andere instellingen, en met de specialisten van SURF, te praten over IAM-onderwerpen die nu actueel zijn bij jouw eigen instelling.

Uiteraard zijn een aantal zaken wel zoals je van standaard SURF-bijeenkomsten gewend bent: een mooie locatie (midden in Utrecht), een goede lunch en een gezellige borrel achteraf.

Er zijn nog wat plaatsen beschikbaar, dus schrijf je snel in.

Vraag van de maand van het IAM-forum (vvdmIAMf)

De vraag van de maand van september is die van Jeroen Koedoot, functioneel beheerder bij Codarts Rotterdam. 

Docenten waarbij het contract afloopt, worden direct gedeprovisioned. Jeroen vraagt zich af hoe andere instellingen omgaan met het feit dat docenten na einde contract nog officiële taken hebben voor de instelling, bijvoorbeeld het beoordelen van hertentames en hiervoor nog toegang tot systemen nodig hebben.

Deze vraag zorgde voor veel herkenning en een levendig gesprek tot gevolg. Mocht je nog toevoegingen hebben, ga naar het topic en laat je ideeën achter. 

Heb je jezelf nog niet aangemeld, gewoon doen op iam.surf.nl!

IAM-specialisten onder elkaar: drie vragen aan Johan Hoeke (Tilburg University

Dit jaar laten we elke maand een IAM-specialist uit de SURFconext-community aan het woord, zodat jullie elkaar ook via SURFconext Nieuws wat beter kunnen leren kennen. Deze maand: Johan Hoeke. Vind je het zelf leuk om deel te nemen aan deze rubriek, dan horen we graag van je. Stuur een mailtje naar support@surfconext.nl.

Welke functie heb je bij je instelling? Waar houd je je mee bezig?
Ik werk bij het team Infra van Library & IT Services van Tilburg University, met als specialisatie Unix-beheer. Samen met vijf collega’s beheren we ondermeer zo’n 250 Linux-servers, grotendeels VM’s die op VMware draaien. Een van de toepassingen die we op Linux draaiden was SimpleSAMLphp, waarmee we de SSO voor de universiteit verzorgden. Daarnaast trad deze op als IdP, onder meer voor SURFconext. Vandaar dat de rol van SURFconext-verantwoordelijke bij ons team ligt. We hebben uiteraard ook een aparte afdeling met IAM-specialisten; dat is weer een ander team 🙂.

Welke grote uitdaging zie je voor je instelling, op het gebied van identity- en accessmanagement? Waarom?
Momenteel delen wij groepsinformatie uitsluitend via eduPersonEntitlement en standaardattributen zoals eduPersonAffiliation. Ik verwacht dat we daar niet veel langer mee wegkomen: er is steeds meer vraag naar fijnmazigere toegangscontrole. SURFconext biedt hiervoor methodes, maar die hebben wij nog niet geïmplementeerd. Daarnaast vullen we nu vanuit IAM zowel onze Microsoft-omgeving als onze Unix-LDAP met gebruikers- en attributeninformatie. Het gebruik van OpenLDAP gaan we afbouwen.

Als een instelling nog twijfelt over SURFconext, wat zeg je dan tegen die instelling?  Waarom zouden ze wel of niet met SURFconext aan de slag moeten gaan?
Bij ons geldt de policy “SURFconext tenzij”, en dat bevalt uitstekend. Binnen SURFconext werken specialisten die zich dagelijks met deze materie bezighouden. Dat is een groot verschil met systeembeheerders die hun aandacht moeten verdelen over veel verschillende kennisgebieden. Ook serviceproviders kunnen terecht bij SURFconext-support (waarvoor dank!): zij moeten hun koppeling immers afstemmen op SURFconext en niet meer rechtstreeks op onze IdP. Dat scheelt ons veel tijd, die we aan andere zaken kunnen besteden.

Attribuut van de maand: mail

Het attribuut mail is het meest gebruikte en herkenbare attribuut binnen SURFconext. Het geeft het e-mailadres van een gebruiker weer, het adres waarop iemand bereikbaar is binnen de instelling. Hoewel het een eenvoudig attribuut lijkt, speelt het in veel diensten een cruciale rol bij communicatie, accountbeheer en notificaties. 

In de SAML-koppeling van jouw instelling met SURFconext, ziet dit attribuut er als volgt uit:

• urn:mace:dir:attribute-def:mail
• urn:oid:0.9.2342.19200300.100.1.3       

De kenmerken op een rij:

• Waarde en datatype: de waarde is een geldig e-mailadres volgens RFC 5322, met een maximale lengte van 256 tekens. Bijvoorbeeld piet.jansen@universiteit.nl.
• Multi-valued: meerdere e-mailadressen zijn toegestaan. In de praktijk wordt mail meestal als single-valued attribuut gebruikt, maar technisch kan het meerdere waarden bevatten als een gebruiker meerdere adressen heeft. En let hierbij op, er is geen eenduidige regel voor diensten om met meerdere waarden om te gaan. Sommige gebruiken alleen de eerste, andere vragen de gebruiker om te kiezen. Daarom is het voor IdP’s, in het belang van interoperabiliteit, aan te raden om waar mogelijk slechts één waarde door te geven.
• Gebruik: dit attribuut wordt door diensten gebruikt voor communicatie met gebruikers (zoals notificaties of accountbeheer), maar ook om accounts te koppelen of te identificeren.
• Scope: de waarde van mail hoeft niet noodzakelijk overeen te komen met de scope van de instelling (zoals bij eduPersonPrincipalName). Het gaat om een daadwerkelijk functionerend e-mailadres, niet om een identifier, en het hoeft niet per se een instellingsadres te zijn

Het gebruik van dit attribuut is wijdverbreid binnen de federatie SURFconext. Op het moment van schrijven ontvangen van de 4.224 geregistreerde diensten in SURFconext er maar liefst 2.318 het attribuut mail. Dat onderstreept hoe belangrijk het is om dit attribuut goed en consistent te beheren. 

Wijzig dit attribuut (liever) niet
Als het e-mailadres van een gebruiker verandert, kan dat vervelende gevolgen hebben. Veel diensten gebruiken dit attribuut namelijk als identificerend attribuut of om accounts te koppelen. Wanneer het domeindeel achter de @ (de ‘scope’) wijzigt, bijvoorbeeld door een instellingsfusie, een hernoeming van het domein, of het overschakelen naar een nieuwe e-mailstructuur,  kan een dienst de gebruiker niet meer herkennen als dezelfde persoon als de dienst op mail vetrouwd. Dit kan leiden tot verlies van toegang, dubbele accounts of verwarrende en foutieve notificaties. 

Wijzig je dit attribuut toch, dan is het verstandig om vóór zo’n wijziging in overleg te gaan met aangesloten diensten die het attribuut mail gebruiken, zodat zij tijdig hun configuratie of gebruikersdata kunnen aanpassen. Wij dringen er bij diensten op aan om een persistenter attribuut te gebruiken, zoals eduPersonPrincipalName of geheel anoniem met eduPersonTargetedID, om gebruikers blijvend te kunnen herkennen, maar veel diensten vertrouwen desondanks op mail. 

Aandachtspunten 

• Gebruik mail niet om een gebruiker uniek te identificeren, daarvoor is het NameID (of  eduPersonTargetedID) bij uitstek geschikt. Of gebruik een attribuut als eduPersonPrincipalName of uid. 
• Een e-mailadres kan in de loop van de tijd veranderen, en soms zelfs door de gebruiker zelf worden aangepast. Dit maakt mail ongeschikt voor authenticatie- of autorisatiedoeleinden ook al wordt het daar wel vaak voor gebruikt.
• Een e-mailadres is niet per definitie het instellingsadres van de gebruiker; hoewel zeldzaam wordt soms een persoonlijk of extern adres gebruikt.
• Het is voor eindgebruikers van belang  dat ze begrijpen dat dit adres mogelijk zichtbaar is voor diensten. 

Tot slot
Mail is geen uniek attribuut is en kan met de tijd veranderen. Ondanks deze evidente nadelen vormt het een belangrijk element tussen identiteit, communicatie en dienstverlening voor meer dan de helft op SURFconext aangesloten diensten.

Afscheid van het CXT-ticket

In 2011 werd de SURFfederatie opgevolgd door SURFconext. Daar hoorde natuurlijk ook ondersteuning bij, en sinds december 2011 hebben we dat gedaan via de bij jullie bekende CXT-tickets. 

Het portaal dat we daarvoor gebruikten, was echter al een tijdje toe aan een upgrade. Die vernieuwing, samen met de wens om één centrale plek te hebben voor al jouw vragen aan SURF, heeft ervoor gezorgd dat je nu een SD-ticket van ons ontvangt wanneer je contact met ons opneemt. 

Er is dus geen reden tot paniek of verwarring: je kunt gewoon blijven mailen naar support@surfconext.nl, wij pakken je ticket op zoals je gewend bent. Als bonus kun je nu ook met jouw instellingsaccount en SURFconext  inloggen op de SURF Servicedesk, waar je al jouw tickets kunt bekijken. Maar je mag ook blijven mailen!  

De SP- en IdP-dashboards werken voorlopig nog via CXT-tickets, omdat daar aanpassingen aan de API’s voor nodig zijn. Daar gaan we de komende weken mee aan de slag.

Nieuwe diensten

Een greep uit de diensten die afgelopen maand zijn aangesloten op SURFconext. Zie voor meer informatie het SURFconext Dashboard of de website van de leverancier. Let op, voor de meeste diensten is een licentie vereist. Neem dus eerst contact op met de leverancier of support@surfconext.nl.

Marvia: marketing platform

Open Learnity: hosting voor online cursussen

Perito: assessment platform