This is the home of the Science Collaboration Zone space.

Onderzoekers die (internationaal) willen samenwerken en aanbieders die onderzoeksfaciliteiten willen aanbieden aan samenwerkingsverbanden, lopen bij het organiseren van de toegang tot elkaars diensten tegen een aantal uitdagingen aan die bij elke nieuwe samenwerking relatief veel inspanning kosten. De Science Collaboration Zone (SCZ, FIAM voor samenwerkende onderzoekers) probeert een aantal zaken op gebied van authenticatie, autorisatie en policies op te lossen.

Deze pagina is voor mensen die meer willen weten over de SCZ. De SCZ wordt momenteel door SURF ontwikkeld op basis van use-cases en scenario's van een aantal instellingen. In het project wordt ook bekeken óf en zo ja hoe de SCZ door SURF als dienst kan worden aangeboden.

Waarom de SCZ?

Voor samenwerking tussen onderzoekers zijn er een aantal specifieke problemen, die we met de SCZ gaan onderzoeken:

Er moet 'iets' geregeld worden om mensen uit te nodigen die toegang moeten hebben tot resources (invites, enrollment).
Het daadwerkelijk toegang geven van uitgenodigde mensen tot resources kost nu vaak relatief veel tijd ('accountbeheer', provisioning etc). Naast webgebaseerde diensten betreft dit ook nadrukkelijk non-web diensten waarvoor op dit moment geen mogelijkheden tot federatieve authenticatie bestaan (denk aan resources die via SSH of webDAV ontsloten worden).
Toegang geven tot een dienst aan niet-Nederlandse onderzoekers en mensen zonder instellings-account (b.v. van bedrijven die betrokken zijn bij het onderzoek) vergt relatief veel werk.
Er moet vaak een manier worden gevonden voor het beheer van samenwerkingsgroepen.
Op basis van samenwerkingsgroepen kan tevens de toegang tot onderzoeksresources worden georganiseerd. Daarvoor is een oplossing nodig die de groepsinformatie kan omzetten in attributen die vervolgens door de te delen resources (bijvoorbeeld wikis, compute of data) geconsumeerd en geïnterpreteerd worden voor het autoriseren van gebruikers.

In de praktijk wordt op deze punten vaak met veel energie opnieuw het wiel uitgevonden. Samenwerkingen lopen vertraging op in de opstartfase omdat er eerst een oplossing voor de authenticatie en autorisatie uitgerold moet worden. Dat kost (doorloop)tijd en de uiteindelijke oplossing is meestal sub-optimaal. De Science Collaboration Zone wil een oplossing bieden waarmee voor authenticatie en autorisatie op een schaalbare en veilige manier voldaan kan worden aan de hedendaagse samenwerkingswensen.

Hoe biedt de SCZ een oplossing?

In het Science Collaboration Zone-project willen we een oplossing bieden door:

Te zorgen dat partijen die resources willen delen dat kunnen doen via de SCZ, en dat de SCZ zorgt voor eenvoudige beschikbaarheid via eduGAIN.
Te zorgen dat non-web resources via federatieve authenticatie (bv. instellingsaccount) benaderbaar worden (zie voor het waarom elders op deze pagina onder "Waarom federatief 'inloggen'?").
Een omgeving te bieden waar instellingen en samenwerkingsorganisaties snel een samenwerkings-groep kunnen aanvragen, daaraan groepsmanagers kunnen toewijzen en vervolgens die groep zelf kunnen beheren, mensen kunnen uitnodigen etc.
Te zorgen voor een mogelijkheid om specifieke attributen te beheren per samenwerkingsgroep.
Te zorgen dat mensen zonder edu-account ook eenvoudig uitgenodigd kunnen worden en de resources kunnen benaderen, waar mogelijk met een hoger 'Level of Asssurance' dan met een social identiteit gebruikelijk is.
Te zorgen dat een instelling slechts 1 maal hoeft aan te sluiten bij de SCZ om hiermee al haar onderzoekers (via één of meerdere samenwerkingen) toegang te geven tot de deelnemende diensten en resources van hun samenwerkingen.

Om een extra idee te krijgen van wat SCZ vooralsnog wil bieden, delen we hier de 'user stories' (in hoofdlijnen) waarvoor we met SCZ een oplossing willen bieden.

Schematische opzet van de SCZ

Schematisch zien we de SCZ momenteel als volgt voor ons:

Het bovenstaande plaatje toont dat de onderzoeksdiensten met de SCZ-proxy worden gekoppeld: die diensten hoeven dus maar 1 koppeling te maken en te onderhouden. Het plaatje toont de features van de SCZ:

Koppeling met SURFconext zodat onderzoekers bij Nederlandse instellingen via SURFconext gebruik kunnen maken van de onderzoeksdiensten.
Biedt een mogelijkheid om diensten te gebruiken voor mensen zonder edu-account (zoals via Google en/of andere social accounts).
Koppelt met eduGAIN zodat onderzoekers bij instellingen buiten Nederland de onderzoeksdiensten kunnen gebruiken.
Zorgt voor een mechanisme (via COmanage) om gebruikers uit te nodigen en groepen en attributen te beheren.
Zorgt voor een oplossing om non-web-diensten veilig te ontsluiten.

Planning / status

In juni 2017 is fase 1 van het project afgerond, en fase 2 gestart. In fase 1 zijn use-cases opgesteld en afgestemd met een aantal samenwerkingsorganisaties, is een architectuur opgesteld en zijn de behoeften gepeild. Fase 2, die vanaf nu tot het derde kwartaal van 2018 loopt, staat in het teken van realisatie van de verschillende componenten en door middel van pilots ervaring opdoen.

SCZ fase 2 richt zich op:

Een grootste-gemene-deler dienst bouwen voor de use cases en pilots.
Het opbouwen van de SCZ technische infrastructuur
Het opstellen van de SCZ-policy.
Het toetsen van de SCZ technische infrastructuur en policy aan de beschreven use cases.
Ervaring opdoen met de SCZ door pilot projecten met instellingen
Het opstellen van een business case.

Planning

Aug/Sep 2017 - Inrichten pilotomgeving
Okt/Nov 2017 - Aansluiten backendsystemen
Okt/Nov 2017 - Inrichten en testen deployment-flows
Okt-Dec 2017 - Inrichten en finetunen toegang “externen”/”gasten”/etc
Okt 2017 - Mei 2018 - Pilot:
- Toegang “gewone” gebruikers
- Finetunen flows
- Meer diensten aansluiten
- Platform doorontwikkelen
Q3 2018 - go/nogo SCZ fase 3 (dienstontwikkeling of gerealiseerde gecontroleerd afbouwen)
Tot eind 2018 - Ongeacht besluit (go of nogo) worden pilot partners tot eind 2018 ondersteund.

Deelnemende instellingen

De volgende instellingen en partijen hebben aangegeven mee te willen doen met de pilot:

UvA/HvA
BBMRI (UMCs)
U2Connect (iRODS)
CLARIAH
Aeneas

Partijen die interesse hebben getoond/waar contacten mee zijn in verband met de SCZ: Deltares, TraIT/Lygature, TUe, Donders Institute, VUmc, uTwente/ NLeScience City Cloud Project, AuthorE/TrustDocA/ErasmusMC.

Van betrokken instellingen wordt verwacht dat ze deelnemen aan bijeenkomsten en de juiste mensen binnen de instelling in voldoende mate laten werken aan/in/met de pilotomgeving, feedback ophalen en met SURF delen en nieuwe features en requirements definieren en zo samen met SURF definieren hoe een SCZ-dienstverlening eruit moet komen zien. De deelnemende instellingen gaan tussen oktober 2017 en mei 2018 testen of wat er gerealiseerd is, voor hun use case(s) voldoet en of de koppelvlakken goed werken.

Interesse of vragen? Zie onder 'Meer informatie'.

Welke technische componenten worden gebruikt?

Waar mogelijk wordt uiteraard van 'bewezen technologie' gebruik gemaakt. We realiseren de SCZ door vanuit functionaliteiten te werken. We analyseren bestaande (vaak open source) componenten op inzetbaarheid, en verbeteren waar nodig en mogelijk de werking zodat ze optimaal samen werken. Om een idee te geven van technologieen en concepten die worden overwogen en/of gebruikt:

COmanage
COmanage is een door Internet2 gestart initiatief waar al jaren, ook in AARC-verband, aan is ontwikkeld en mee getest en gepilot is. Van alle oplossingen die er op gebied van afhandelen van beheer van groepen, uitnodigen van mensen (invite-flows) zijn, lijkt dit de meest toekomstzekere. SURF kan ondermeer de relatie met de ontwikkelaars achter COmanage benutten.
SATOSA
SATOSA ("A configurable proxy for translating between different authentication protocols such as SAML2, OpenID Connect and OAuth2") gebruiken we in deze fase als basis om webapplicaties aan te sluiten, voor afhandelen van authenticatieverzoeken en het tonen van een WAYF.
pyFF
Voor metadata handling en de WAYF
CMService
Voor de Consent
LDAP
Samen met COmanage en SATOSA vormt de LDAP de technische basis voor de SCZ. In de LDAP worden applicatie specifieke wachtwoorden (ASP), public ssh/pgp keys, gridcertificaten etc opgeslagen en ontsloten voor non-web applicaties.
Gastgebruik
Met gastgebruik is binnen SURF voor o.a. SURFconext veel ervaring (momenteel wordt binnen SURFconext OneGini gebruikt als gast-IdP). SURF-medewerkers zijn de afgelopen jaren in AARC-verband ook betrokken geweest bij projecten waarbij de vraag was hoe gasten toegang konden krijgen, en dus ook bij bedenken van oplossingen daarvoor in verschillende scenario's/contexten.
Account Linking
Mensen hebben meerdere online identiteiten die hun eigen toegevoegde waarde hebben. Sommige mensen hebben meerdere instellings-accounts, soms is een nationale identiteit of een bank-id handig etc. Daarom is er in de SCZ-context, met veel mensen van verschillende instellingen en met veel nationaliteiten, behoefte om op een veilige betrouwbare manier identiteiten (accounts) aan elkaar te linken.
Sterke Authenticatie
Diverse diensten die aan de SCZ worden gekoppeld bevatten gevoelige gegevens waarvoor het nodig is dat sterke authenticatie wordt gebruikt voordat mensen toegang hebben. Het project kan bouwen op jarenlange ervaring die SURF heeft met onderzoek naar Levels of Assurance (LoA's) en ontwikkelen en leveren van SURFconext Sterke Authenticatie.
Federatief ontsluiten van non-web resources (via bijvoorbeeld SSH en webDAV)
Voor webapplicaties is het relatief eenvoudig om authenticatie op federatieve wijze te implementeren door het SAML of OIDC protocol te ondersteunen in de applicatie. Diensten die zich richten op onderzoekers hebben vaak geen web-schil, maar gebruiken de authenticatie van SSH en webDAV, protocollen die standaard geen federatief model ondersteunen. De SCZ gaat de toegang tot en beheer van zulke 'non-web'-bronnen op een pragmatische manier organiseren: aanbieden van koppelvlakken op de LDAP (waaronder PAM).
Containerization
Binnen het SCZ-project wordt gekeken of het gebruik van containers voordelen biedt op gebied van bijvoorbeeld schaalbaarheid, beheer, stabiliteit, beschikbaarheid etc.

Waarom federatief 'inloggen'?

Zorgen dat een dienst/resource 'federatief' gekoppeld wordt, betekent dat gebruikers met hun instellingsaccount kunnen 'inloggen' (authenticeren): zodra ze een dienst willen benaderen, worden ze 'vanzelf' doorgestuurd naar het inlogscherm van hun instelling (of andere organisatie waar ze een account hebben, als dat gebruikt mag worden, zoals een bank). Redenen om dat zo te regelen:

Het zorgt voor meer betrouwbaarheid
- Als dienst/resource heb je zekerheid over de identiteit
- Als een medewerker bij een organisatie vertrekt en dus mogelijk geen toegang meer moet hebben tot een dienst/resource, zorgt federatieve authenticatie dat toegang ook niet meer mogelijk is
Het zorgt voor schaalbaarheid
- Als dienst/resource heb je geen/minder werk aan het aanmaken van een account, het ondersteunen van gebruikers die hun wachtwoord vergeten etc
Het vergroot de veiligheid
- Gebruikers kunnen hun (sterke) instellings-wachtwoord gebruiken en hebben niet 'nog' een account en wachtwoord om te managen
- Gebruikers hoeven alleen hun wachtwoord in te vullen op het voor hen bekende instellings-inlogscherm (hoe minder afwijkende schermen om wachtwoorden vragen, hoe minder gevoelig gebruikers zijn voor phishing)
Het zorgt voor gebruikersgemak
- Met slechts 1 al bestaand en bekend username / password nog meer diensten kunnen gebruiken en geen/minder extra aparte inloggegevens

Wordt dit een dienst van SURF?

SURF voert de pilots uit om ook op deze vraag antwoord te krijgen. Zo kunnen we na de pilots conclusies trekken over de functionaliteiten: lost de SCZ daadwerkelijk deze problemen op? Ook hebben we een betere inschatting van de mogelijkheid om dit centraal aan te bieden en zo ja, de kosten (in apparatuur en mensen) die nodig zijn om zo'n centrale infrastructuur aan te bieden. In de zomer van 2018 zullen we op basis van de ervaringen uit de pilots een beslissing hierover nemen. SURF heeft voor deze besluitvorming een gestandaardiseerd mechanisme. Uiteraard hebben de pilotpartners aanzienlijke invloed op dit proces. Mocht er worden besloten om de SCZ niet als dienst te gaan aanbieden, dan zullen we met iedere pilotpartners een uitfaseringstraject ingaan, waarbij SURF bijvoorbeeld kan helpen om de functionaliteit lokaal te gaan draaien.

Meer informatie

Interesse? Vragen? Suggesties? Mail met Raoul Teeuwen (raoul.teeuwen@surfnet.nl ).

Science Collaboration Zone Home