SURFconext & autorisatie Inventarisatie van problemen en wensen Seminar What's Next @ SURFconext 24 maart 2015 Ton.Verschuren@m-7.nl

Interviews UMC Utrecht KNAW Saxion Hogeschool Hogeschool Leiden Avans Hogeschool Universiteit van Amsterdam Universiteit Maastricht Open Universiteit Rijksuniversiteit Groningen

Attributen in de keten S IdM AD/LDAP ADFS / AM SC SP ABAC model Attributen zetten obv bedrijfsregels en schema Attributen zetten obv bedrijfsregels Mapping lokale op federatieve attributen Bron Filtering van attributen Autorisatie obv attributen

Organisatorische aspecten Bij aansluiten nieuwe SP zijn 4 partijen betrokken: instelling (IdP), SURFnet, SURFmarket, dienstverlener (SP) Wens dat SURFnet en SURFmarket 1 loket leveren Wens dat SURFnet meer helpt met communicatie naar SP Zou bewerkersovereenkomst tussen IdP en SP overgenomen kunnen worden door SURFmarket? Aangepast normenkader voor diensten met lage privacygevoeligheid aangeboden door instellingen zelf? Juridisch normenkader cloudservices hoger onderwijs de privacybepalingen die je zou opnemen in een bewerkersovereenkomst zijn opgenomen in het HO juridisch normenkader. Dit normenkader is integraal overgenomen in de bemiddelingsovereenkomst en de aansluitovereenkomst. Voor de aansluitende service-providers geldt een comply or explain

Instellingskant Schemawijzigingen (eduPerson) in AD soms niet gewenst Soms geen test/acceptatieomgeving, dus testen nieuwe attributen gebeurt in productie Mapping van lokale naar federatieve attributen gebeurt vaak in koppelvlak naar SC (AM, ADFS, SiSaPhp), maar dat is vaak voor vrij generieke attribu(u)t(waard)en Attributen zetten voor individuen (beheerrol) vaak lastig Best practise: voor beheerrol-achtige attributen security groep in AD maken en mappen in ADFS-config Scenario’s van UB worden slecht ondersteund (WAYF, walk-by users, privacy, deep-linking) Vaak wel een proces (via servicedesk) om vragen om (vulling) attribuut af te handelen Betere tooling (inclusief delegatie) voor zetten attributen gewenst Meer transparantie. Meer kennis & best practise voorbeelden.

SURFconext kant Beschikbaarheid moet net zo goed als internetaansluiting Autorisatie op doorgifte attributen naar SP (bv 1 faculteit doorlaten naar SP) als SP geen entitlement ondersteunt Betere integratie SC Dashboard en Teams: 1 plek om alles te beheren Dashboard: kunnen zoeken op naam attribuut en door welke diensten dat gebruikt wordt Betere tooling gericht op het voeren van regie op de autorisaties Instellingsspecifieke foutmeldingen bij SC (zoals vroeger…) Graag centraal OAuth-koppelvlak (autorisatieserver) Koppeling DigiD via SC zou handig zijn ivm de zware audit van Logius Veel interesse in step-up authenticatie (sterkere authenticatie ook als autorisatie)

Aanbiederskant Meer ondersteuning voor entitlements Betere ondersteuning groepen Federatieve (de)provisioning blijft een uitdaging Aparte ingang bij SP per IdP ipv WAYF Wijzigingen in benodigde attributen bij bestaande koppeling met SP zijn lastig en eigenlijk ongewenst

Groepen Groot verschil tussen instellingen in gebruik groepen Vrijwel altijd in ieder geval voor KA-toepassingen (AD security groepen) Onduidelijk welke SP’s groepen ondersteunen Onderscheid rol en groep niet altijd helder (bv alle medewerkers) Teveel groepen per gebruiker levert problemen op (lengte waarde attribuut) Meer transparantie gewenst bij naamgeving groep en bijbehorende autorisatie SC uitbreiden met Grouper instantie per instelling?

Hoe verder? Inventarisatie leidt tot rapport Kennisoverdracht verbeteren (te beginnen vandaag !) Aparte sessies met instellingen over dit onderwerp SURFnet neemt dit mee in de roadmap voor SURFconext Disclaimer voor verwachtingsmanagement… Sessies vanmiddag