Algemeen

Zijn de opnames, voor mijn collega's die er nu niet bij zijn, terug te kijken?

Zeker, de opnames staan online:

eduID

Moeten gast-onderzoekers ook eduID gebruiken?

Om de vraag goed te kunnen beantwoorden is het belangrijk om eerst stil te staan bij wat een gast-onderzoeker precies is. Is dat een onderzoeker van een andere instelling (al dan niet uit Nederland) of is dat een onderzoeker die werkt bij een bedrijf/instelling die niet beschikbaar is via SURFconext / SURF Research & Access Management (SRAM) / eduGAIN?

Meestal zullen gast-onderzoekers al een eigen instellingsaccount hebben. Is dat het geval, dan kunnen zij inloggen met dit account op diensten aangesloten op SRAM. Een (extra) eduID-account is dan niet nodig.

Voor gastgebruikers (dus ook onderzoekers) die geen instellingsaccount hebben, heeft een instelling meerdere mogelijkheden. Sommige instellingen geven bijvoorbeeld voorkeur aan het uitdelen van een lokaal account (al dan niet in combinatie met een 0-uren contract). Dat kan vooral handig zijn als deze gast-onderzoeker ook toegang moet hebben tot (interne) applicaties die niet zijn aangesloten op SURFconext of SRAM. Gast-onderzoekers kunnen met dat (al dan niet tijdelijke) account van de instelling dan ook via SURFconext / SRAM inloggen op diensten en hebben dus geen eduID-account nodig.

Gaat het om een gast-onderzoeker die niet al over een instellingsaccount beschikt en ook geen account van de 'gastinstelling' krijgt, dan kunnen zij eduID gebruiken. eduID biedt toegang tot enkele diensten via SURFconext (namelijk diensten die 'gastgebruik' toestaan) en diensten via SRAM.

Is eduID ook als centraal e-portfolio te gebruiken?

Zoals eduID nu is opgezet niet. eduID is een digitale identiteit, onafhankelijk van de instelling. En met eduID kan de student, onder zijn eigen regie, gegevens van autoritatieve bronnen vrijgeven aan een dienst die dit wil gebruiken. Dit soort gegevens willen we bij voorkeur niet in eduID opslaan vanwege de privacy. Er is wel een initiatief van de overheid, eduMIJ (naar analogie van medMij in de zorg) dat mogelijk wel een digitaal portfolio kan worden. Maar het is nog te vroeg om hier iets concreets over te zeggen: het is nog onzeker of en hoe dit geïmplementeerd zal worden.

Kun je iets zeggen over een eduID-systeem op Europees niveau?

We zijn geregeld in gesprek met andere landen die soortgelijke eduID's aanbieden om kennis en ervaring uit te wisselen. Ter ondersteuning hiervan organiseerde SURF afgelopen voorjaar de internationale eduID day 2020. Verder zijn er binnen Europa ook op andere vlakken ontwikkelingen op het gebied van studentmobiliteit, zoals de MyAcademicID-dienst die, via eduGAIN, Erasmus without Paper-diensten ontsluit (ter ondersteuning van de Erasmus-uitwisselingen). SURF volgt deze ontwikkelingen nauwgezet.

Staat het mbo ook op de stoep voor eduID?

We zijn geregeld in gesprek met het mbo. Raakvlakken zijn er bijvoorbeeld voor ECK-ID en het centraal inschrijven. Op dit moment zijn dit nog hoog over gesprekken en is er nog geen concrete samenwerking op één van deze of andere gebieden. Maar, we zijn altijd op zoek naar goede toepassingen en pilots, ook in het mbo!

Een instellingsaccount is een 'vertrouwd' account, eduID een gast-account, hoe krijg je daar vertrouwen in?

Op dit moment kan de betrouwbaarheid van een eduID-account op 1 manier worden verhoogd, namelijk door het te koppelen aan een instellingsaccount. De edubadges-dienst van SURF maakt hier bijvoorbeeld gebruik van om er zeker van te zijn dat edubadges aan de juiste studenten worden uitgedeeld. Lees meer hierover in de eduID-nieuwsbrief. Meer technische informatie hierover vind je op de SURFconext-wiki: Koppelen met eduID Account Linking.

Op termijn verwachten we deze functionaliteit verder uit te breiden en andere 'bronnen' toe te voegen. Zo willen we middels een proof of concept bekijken of een koppeling met DigiD op basis van een pseudoniem (van het BSN) mogelijk is. Ook zullen we experimenteren met IRMA, waarmee het mogelijk is attributen uit de Basisregistratie Persoonsgegevens te gebruiken. Beide koppelingen zullen leiden tot een hogere betrouwbaarheid van het eduID.

Het eduID-team komt graag in contact met geïnteresseerden in deze functionaliteit. Na een proof of concept passen we dergelijke koppelingen ook graag toe binnen geschikte use cases, om vervolgens in een pilot de geschiktheid van de koppelingen te bepalen.

Interesse? Neem contact op met Peter Clijsters, productmanager eduID.

SURF Research Access Management (SRAM)

Kan ik SURF Research Acces Management (SRAM) nu ook al gebruiken als instelling?

Ja. Als instelling kun je SRAM op 3 manieren gebruiken:

  1. Je kunt je IdP koppelen, zodat je eigen onderzoekers op uitnodigingen kunnen ingaan die vanuit SRAM door andere instellingen worden verstuurd, en daarmee kunnen je onderzoekers ook optimaal de instellings-identiteit gebruiken.
  2. Je kunt eigen diensten aan SRAM koppelen, zodat die voor onderzoekssamenwerkingen beschikbaar komen.
  3. Je kunt de dienst afnemen/bestellen bij SURF, waarmee je de mogelijkheid krijgt onderzoekssamenwerkingen waarvoor je instelling verantwoordelijk is 'in SRAM aan te maken' waardoor het aanmaken en beheren van accounts in diensten veel veiliger wordt en minder tijd kost.

Twee kanttekeningen: 1) contractueel zijn we de laatste punten op de i aan het zetten. We hopen dat dat binnen enkele weken is afgerond en 2) SRAM is een jonge dienst. In de loop van de tijd zullen steeds meer diensten technisch gekoppeld zijn aan SRAM, waardoor ze met een paar kliks in gebruik zijn te nemen door een onderzoekssamenwerking, maar dat aantal diensten moet in het begin natuurlijk groeien. Het éénmalig technisch aan SRAM koppelen van diensten kost wel degelijk wat inspanning en werk. Meer informatie, onder meer over hoe het aan te vragen vind je op https://wiki.surfnet.nl/display/SRAM/SRAM+for+institutions.

Federatieve toegang voor bibliotheken

Bij welke Rotterdamse bibliotheek werkt de huidige spreker, Jos Westerbeke, die nu spreekt over AAI voor bibliotheken? Erasmus of de (Centrale) openbare bibliotheek?

Jos Westerbeke is Demand Manager en Library IT Specialist op de University Library bij de Erasmus University Rotterdam (EUR).

Zijn de hogeschoolbibliotheken al aangesloten?

Binnen Nederland heeft SURF contact met de Nederlandse universiteitsbibliotheken de Koninklijke Bibliotheek (UKB) en het Samenwerkingsverband Hogeschoolbibliotheken (SHB). We bespreken met hen welke attributen idealiter (slechts) worden uitgewisseld met publishers, waarbij we streven naar minimalisatie. Steeds meer uitgevers conformeren zich inmiddels al aan dat minimum. Een aantal uitgevers dat nog niet hieraan voldoet, heeft inmiddels toegezegd hun systemen hierop aan te gaan passen. Het vergt inspanning van SHB/UKB, SURF en instellingen om ook die uitgevers die nog geen toezegging hebben gedaan, zo ver te krijgen. Zie ook https://communities.surf.nl/artikel/surfconext-minimaliseert-attributen-contentdiensten.

Hoe staan uitgevers hierin? Zijn hier contacten mee?

Zie ook de vraag hierboven: naar aanleiding van gesprekken tussen UKB/SHB en SURF over welke gegevens (attributen) uitgewisseld kunnen worden, is SURF in gesprek gegaan met uitgevers.

Microsoft Azure AD, SURFconext en/of SURFsecureID: best of both worlds

Remote vetting voor SURFsecureID?

Met remote vetting willen we mogelijk maken dat een gebruiker van SURFsecureID helemaal zelfstandig een 2e factor kan registreren en activeren. Daarvoor zetten we momenteel een poof of concept (PoC) op. De bedoleing is om die eind 2020 live te hebben. Op basis van de uitkomsten van de PoC besluiten we - samen met de leden - hoe we verder gaan. Aan de implementatie en gebruik van remote vetting zullen namelijk kosten verbonden zijn.

In de PoC richten we ons op twee zaken:

  1. De gebruikerservaring van de verschillende authenticatie-methodes die we voor remote vetting willen gaan gebruiken:
    1. NFC-chip identeitsbewijs met selfie
    2. IRMA-attributen verkregen uit een DigiD-authenticatie
    3. een iDIN-authenticatie
  2. Het matchen van de naamsgegevens zoals we die van de instelling ontvangen met de naamsgegevens zoals we die van de verschillende remote vetting methodes ontvangen. Dit is onderdeel van de "vetting" in remote vetting. Het formaat van de naam uit de verschillende bronnen verschilt. In de PoC gaan we naamsgegevens van echte gebruikers verzamelen. Op basis van die gegevens willen een matching algoritme ontwikkelen.

Voor de PoC zoeken we dus echte gebruikers die de verschillende methodes willen uitproberen. Wil je daar aan meehelpen? Stuur een mail naar support@surfconext.nl.

Is er een mogelijkheid voor een gebruiker om in SURFsecureID van een gevet SMS token te migreren naar een Tiqr of Azure MFA token zonder het vetting proces opnieuw te doorlopen?

Voor komend jaar staat op de planning om dit als nieuwe feature toe te voegen. Een gebruiker met een bestaand token kan dan een nieuw token registreren, zonder dat opnieuw het vetting proces hoeft worden doorlopen.

Wij zijn bezig met het aansluiten van SURFSecureID op onze Azure omgeving voor MFA. Jullie geven in mail-correspondentie aan dat ADFS nodig blijft voor het aanzetten hiervan. Echter wordt er in deze presentatie gesproken over ADFS OF Azure AD.

Voor het gebruiken van Azure MFA als token wordt een koppeling gemaakt met de SURFsecureID. Deze koppeling kan zowel met ADFS als met Azure AD worden gemaakt. De tweede factor wordt altijd afgehandeld door Azure. Een rechtstreekse koppeling met AzureAD is dus logischer, maar niet noodzakelijk.

Als je SURFsecureID wilt gebruiken voor diensten die via Azure AD zijn aangesloten, bijvoorbeeld Office365, dan blijft een lokale ADFS nodig, omdat Microsoft het nog niet mogelijk maakt eigen MFA-diensten direct op Azure AD aan te sluiten. Een test hier mee ("Azure Custom Control") is door Microsoft stopgezet.

MFA in Azure AD: hebben jullie good practices?

Hoe je als instelling het beste MFA in Azure AD kunt implementeren is erg afhankelijk van de eigen situatie. Ook is er binnen SURF niet veel expertise aanwezig op het gebied van MFA in Azure. We zien dat veel instellingen Azure MFA gebruiken, maar ook instellingen die SURFsecureID gebruiken. Voor dit laatste wordt vooral gekozen als de hogere betrouwbaarheid belangrijk is voor diensten die aan Azure gekoppeld zijn.

Kijken jullie naar een native integratie van SURFsecure ID als een custom control in Azure AD conditional access, zodat we ADFS bij die integratie over kunnen slaan en SURFsecure als Azure AD MFA kunnen gebruiken

Jazeker. Microsoft had een tijd geleden de Custom Control functionaliteit in preview en we hebben hard geprobeerd daar aan mee te mogen doen, maar helaas is dat niet gelukt. Microsoft heeft begin dit jaar besloten niet met Custom Controls verder te gaan omdat deze functionaliteit te beperkt was (zie de blog van Alex Simons). We houden de ontwikkelingen in de gaten en als Microsoft met de mogelijkheid komt om 3rd party MFA rechtstreeks te integreren in Azure, dan gaan we daar snel mee aan de slag.

Toekomstbestendig en te adviseren autorisatie-protocol  (OAuth2, Kerberos, ..)

De in onze federatie ingezette protocollen hebben een grote tractie wereldwijd: SAML 2.0, OpenID Connect en OAuth zijn industry standard ook buiten de onderwijscommunity. SAML wordt veel gebruikt in enterprise-producten maar is bijvoorbeeld ook de basis van DigiD en Ideal. OpenID Connect is het onderliggende protocol dat gebruikt wordt door grote partijen als Google en Apple voor hun authenticatieplatforms, en OAuth is feitelijk de enige standaard om API's af te schermen.

SURFconext, SURFsecureID en SRAM zijn SaaS-platforms die als authenticatie-proxy optreden en protocoltranslatie eenvoudig mogelijk maken. Zo hebben we al laten zien dat we OpenID Connect kunnen introduceren als koppelvlak zonder dat instellingen hun Identity Provider hebben hoeven aan te passen. Op vergelijkbare wijze kan SURFsecureID ondersteuning voor FIDO2-tokens en Azure MFA toevoegen, ook weer zonder dat Service- en Identity Providers kun koppelingen hoeven aan te passen. We denken daarmee een wendbare opzet te hebben die de gangbare protocollen ondersteunt, maar juist ook de transitie naar nieuwe protocollen kan faciliteren.

Als we nu TIQR ingezet hebben op SURFsecureID, kan de Azure MFA dan naast TIQR worden geregistreerd of dient de TIQR token dan vervangen te worden?

Een SURFsecureID gebruiker kan zowel een AzureMFA-token als een Tiqr-token hebben. Iedere instelling kan aangeven wat het maximum aantal tokens is dat een gebruiker mag hebben, typisch staat dat op 1 of 2. Staat dit nu op 1, dan is het registreren van een tweede token niet mogelijk. Staat dit op 2 dan kan een gebruiker een tweede token registreren. Dit moet altijd een token zijn van een ander type dan dat de gebruiker al heeft. Stuur een mail aan support@surfconext.nl als je het maximum aantal tokens per gebruiker wilt laten aanpassen.

Als een gebruiker twee tokens heeft dan moet de gebruiker bij authenticatie kiezen welk token hij/zij wil gebruiken.

Nu is het nog zo dat een gebruiker voor iedere token registratie gevet moet worden. Volgend jaar willen we het mogelijk dat een gebruiker die al een token heeft dit helemaal zelf kan doen.

Is SURFsecureID onafhankelijk van SURFconext?

Daar is een tweeledig antwoord op:

  • Gebruikers kunnen alleen een SURFsecureID token registreren als ze een account hebben bij een instelling. Dit instellingsaccount wordt ontsloten via SURFconext aan SURFsecureID, dus daar is SURFconext voor nodig.
  • Voor de integratie van diensten met SURFsecureID is SURFconext niet nodig. Er zijn veel diensten met een directe koppelingen met SURFsecureID, dus buiten SURFconext om. Zie voor een nadere toelichting optie 1 en optie 2b op deze pagina: https://wiki.surfnet.nl/x/p_Cl

Overstappen van simpleSAMLphp naar ADFS of Azure AD?

SURFconext is gebaseerd op open standaarden en dat biedt de instellingen de vrijheid om zelf de software en systemen te kiezen die passen in hun IT-architectuur. We adviseren daarom per definitie niet een bepaald product. Er zijn meer dan tien verschillende softwareproducten in gebruik bij IdP's, en zowel simpleSAMLphp als ADFS als Azure wordt elk succesvol gebruikt door tientallen instellingen, en bij elk van die producten zijn het zowel heel grote en juist ook kleine instellingen die het gebruiken. Er dus dus geen advies dat een bepaald product in het algemeen 'beter' zou zijn.

Overstappen van Identity Provider-software is overigens in de regel een overzichtelijke procedure zolang de oude en de nieuwe implementatie dezelfde attribuutwaarden blijven vrijgeven voor de gebruikers. Zijn er moverende redenen om die attribuutwaarden te willen wijzigen, dan kan het SURFconext-team consultancy bieden bij de overgang.

Kan ik SURFsecureID gebruiken om in te loggen op Windows- en Mac-systemen?

Windows en OSX ondersteunen niet direct authenticatie met SURFsecureID. Om SURFsecureID te kunnen gebruiken moet het authenticatie-protocol van SURFsecureID (SAML2) of het authenticatie-protocol van SURFconext (SAML2, OpenIDConnect) ondersteund worden. Een gebruiker met een FIDO2 token kan dit token wel veilig gebruiken voor zowel SURFsecureID, als authenticatie naar de eigen laptop. Ook kan SURFsecureID gebruikt worden voor authenticatie met remote desktop software (bijvoorbeeld van Citrix of F5) die deze protocollen ondersteund.

Duidelijk is dat rondom identity en autorisaties nog volop geëxperimenteerd wordt. Loop ik hierin mee of zal ik afwachten? Of mis ik dan de boot?

Identity & Access Management (IAM) is altijd in beweging en dit zal ook zo blijven. Omdat IAM overal wel een rol speelt en vaak verweven is met de hele organisatie, is het goed om verder vooruit te kijken. Je kan dan tijdig iedereen meenemen en je voorbereiden op veranderingen. Voorbeelden zijn: de invoering van de AVG, multifactor-authenticatie, een fusie of bijvoorbeeld het feit dat de ondersteuning van het gebruikte product gaat aflopen. Als je hier pas laat mee aan de slag gaat, dan zijn dit lastige trajecten. Als je weet dat dit er aan gaat komen, dan kan je zorgen dat de ontwikkeling al de juiste richting op gaat. Het is dus goed om regelmatig te kijken of de huidige oplossing nog voldoet en daarbij moet je ook kijken naar waar de instelling heen wil over 2 tot 4 jaar en welke externe ontwikkelingen er gaan spelen.

Als de instelling bijvoorbeeld voorop wil gaan lopen op het gebied van flexibel onderwijs, dan is het goed om mee te doen aan de pilots van eduID. Je hebt dan echt invloed op de ontwikkeling en je kan jullie use case en visie inbrengen. Als dit geen doel is van jouw instelling, dan kun je beter wachten en je eerst ergens anders op gaan richten.

Waar wordt het Level of Assurance over een SURFsecureID bepaald?

Het Level of Assurance (LOA) van een SURFsecureID wordt bepaald door de betrouwbaarheid van het authenticatiemiddel en de betrouwbaarheid van de identiteit. De laagste score bepaalt het uiteindelijke LOA wat in de authenticatie wordt doorgegeven. De score loopt van 1 tot 4.
Een deel van de LOA wordt dus bepaald door de sterkte van het inloggen. Alleen een wachtwoord is score 1 (LOA1). Een SMS, Tiqr of AzureMFA token is ingeschaald op score 2 (LOA2). En de hardware tokens als Yubikey of de nieuwe FIDO2 tokens hebben score 3 (LOA3).
Het andere deel is de identiteitscontrole bij de instelling, dat bepaalt de betrouwbaarheid van de identiteit. Hierbij bevestigt een vertrouwde medewerker van de instelling dat de gebruiker is wie hij beweert te zijn, en dat hij de eigenaar van het token is. Dit proces scoort LOA3. 

Zie ook: Levels of Assurance

Als de MFA van Azure wordt gebruikt voor SURFsecureID, neemt dan de betrouwbaarheid binnen Azure zelf ook toe?

Dat is een goede vraag. Als je als instelling weet dat een gebruiker zijn Azure MFA token heeft geregistreerd in SURFsecureID, dan zou dat inderdaad kunnen kloppen. Echter, die directe relatie kun je niet altijd leggen. Zo kan iemand zijn Azure MFA token nog niet in SURFsecureID geregistreerd hebben, of is de SURFsecureID-registratie (om wat voor reden dan ook) verwijderd. Omdat je deze relatie niet altijd kunt leggen is het voorzichtige antwoord dat die betrouwbaarheid binnen Azure zelf beperkt toeneemt.

Als je wilt overstappen van ADFS naar AAD als IdP, doen je dat dan via SAML of via OIDC?

Op dit moment kan een instelling (IdP) alleen via SAML aangesloten worden.

  • No labels