Work-in-progress space, to be published in the SCZ Public Space

Deze pagina is voor mensen die meer willen weten over het wat en waarom van de Science Collaboration Zone (SCZ). De SCZ wordt momenteel door SURF en een aantal instellingen ontwikkeld. Afhankelijk van de uitkomsten zal worden gekeken of het een dienst wordt die SURF kan aanbieden.

Waarom de SCZ?

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. SCZ probeert een aantal zaken rondom authenticatie, autorisatie en policies die van toepassing zijn op te lossen zoals:

In de praktijk wordt 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. Resources worden hierdoor slecht besteed 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?

De Science Collaboration Zone wil een oplossing bieden door:

Heb je een plaatje van hoe de SCZ er schematisch uit ziet?

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 onderhouden. Het plaatje toont de features van de SCZ :

Planning / status

Tot juni 2017 is Fase 1 afgerond: er is gesproken met partijen om een idee te krijgen van use-cases, er is voldoende idee ontwikkeld van wat er moet gebeuren, daar is een voorstel voor geschreven en er is draagvlak voor uitvoeren van fase 2, waarbij we 'dingen gaan bouwen' en daarmee pilots gaan doen.

SCZ fase 2 richt zich op:

Planning

Wat verwachten we van deelnemende instellingen?

We verwachten vooral input over wat we moeten bouwen en dat ze hun gebruikers/samenwerkingen actief betrekken in het testen van wat we opleveren. 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.

Welke technische componenten worden gebruikt?

Waar mogelijk wordt uiteraard van 'bewezen technologie' gebruik gemaakt. De SCZ realiseren lijkt vooral op zoeken van sterke componenten die al bestaan, eventueel sommige daarvan verbeteren zodat ze optimaal bijdragen aan/passen in de SCZ, het 'aan elkaar lijmen' van die onderdelen en zaken regelen als een goede policy waarmee voldoende vertrouwen wordt geregeld voor deelnemende partijen. Om een idee te geven van technologieen en concepten die worden overwogen en/of gebruikt:

User stories

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.

Samenwerkingsorganisaties

    1. Als samenwerkingsorganisatie wil ik onderzoeksdiensten delen en laagdrempelig maar veilig toegankelijk maken voor gebruikers van diverse organisaties in binnen- en buitenland

    2. Als samenwerkingsorganisatie wil ik potentieel elk type gebruiker kunnen uitnodigen voor deelname in de samenwerking

    3. Als samenwerkingsorganisatie wil ik web gebaseerde omgevingen met een instellingsaccount toegankelijk maken

    4. Als samenwerkingsorganisatie wil ik non-web gebaseerde omgevingen met een instellingsaccount toegankelijk maken

    5. Als samenwerkingsorganisatie wil ik de toekenning van rechten kunnen delegeren (zie user stories "Managers van samenwerkingsorganisaties")

    6. Als samenwerkingsorganisatie wil ik identiteiten en rollen/rechten uit verschillende bronnen kunnen samenvoegen (proxy)

    7. Als samenwerkingsorganisatie wil ik voor de CO (CO=Collaborative Organisation) relevante diensten als bundel met WAYF naar IdPs presenteren (proxy, ook eduGAIN)

Managers van samenwerkingsorganisaties

    1. Als CO admin wil ik het toegangsmanagement schaalbaar en transparant kunnen regelen

    2. Als CO admin wil ik nieuwe gebruikers kunnen uitnodigen/inschrijven voor deelname in de CO

    3. Als CO admin wil ik rechten en rollen centraal administreren

    4. Als CO admin wil ik de administratie nieuwe gebruikers en hun rechten en rollen kunnen delegeren

    5. Als CO admin wil ik policies kunnen definieren voor herbevestiging van deelname en rechten van gebruikers

    6. Als CO admin wil ik policies kunnen definieren voor deprovisioning van gebruikers

    7. Als CO admin wil ik policies kunnen definieren voor herbevestiging van deelname en rechten van gebruikers

    8. Als CO admin wil ik de audit trails kunnen inzien en reviewen (time stamp nieuwe gebruikers, uitdelen/intrekken rechten)

    9. Als CO admin wil ik de gebruikers en rollen/rechten registry beschikbaar maken voor service providers (LDAP sync e.d.)

Eindgebruiker

    1. Als eindgebruiker wil ik eenvoudig toegang tot gedeelde bronnen

    2. Als eindgebruiker wil ik mij kunnen inschrijven voor een VO (Virtual Organisation)

    3. Als eindgebruiker wil ik toegang tot gedeelde diensten obv mijn instellingsaccount

    4. Als eindgebruiker wil ik toegang tot gedeelde diensten obv van mijn social ID

    5. Als eindgebruiker wil ik mijn accounts kunnen koppelen (account linking, bijv ORCID)

    6. Als eindgebruiker wil ik additionele informatie kunnen registreren (self asserted attributen zoal: mail adres, telefoonnr, titel)

    7. Als eindgebruiker wil ik one time passwords kunnen genereren en registreren

    8. Als eindgebruiker wil ik applicatie specifieke wachtwoorden kunnen genereren en registreren

    9. Als eindgebruiker wil ik ssh keys kunnen registreren

    10. Als eindgebruiker wil mijn deelname in de CO kunnen opheffen

    11. Als eindgebruiker wil ik mijn account kunnen opheffen

Instelling

In de rol van dienstaanbieder

    1. Als dienstaanbieders wil ik op eenvoudige wijze authenticatie- (AuthN) en autorisatie- (AuthZ) informatie kunnen consumeren en mappen op de interne gebruikersadministratie van de dienst

    2. Als beheerder wil ik gebruikers kunnen uitsluiten wanneer deze zich misdragen
    3. Als beheerder wil ik over de juiste logging beschikken om te kunnen bepalen wat een gebruiker gedaan heeft
    4. Als beheerder wil ik over de juiste logging beschikken om te kunnen gebuiken in een security incedent

In de rol van identityprovider

    1. Als identity provider wil ik voldoende zekerheid over de aard, voorwaarden, aansprakelijkheid....van de dienst

    2. Als identity provider wil ik voldoende overzicht over de aansluitvoorwaarden (R&S, CoCo) waardoor ik met voldoende zekerheid approval kan geven

    3. Als identity provider wil ik de autorisatiecomponent van SURFconext kunnen gebruiken om de instellingspopulatie met toegang tot de dienst te kunnen scopen

    4. Als identity provider wil ik dat eind-gebruikers de keuze krijgen om consent te geven voor het delen van instellingsattributen

In de rol van “orchestrator”

    1. Als research ICT afdeling van de instelling wil ik diensten kunnen bundelen en als 1 eindpunt kunnen aanbieden richting identity providers

    2. Als research ICT afdeling van de instelling wil ik (externe) users en hun rollen/rechten kunnen administreren

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:

Wordt dit een service?

Momenteel is nog niet duidelijk hoe deze oplossing 'geexploiteerd'/beheerd gaat/moet gaan worden. Moet dit 'per dienst en bij de instelling' komen te draaien, of kan het als dienst, as-a-service, aangeboden worden? Als het een dienst kan worden, kan en wil SURF die dienst dan aanbieden? Wie gaat de beheer- en onderhoudskosten dan betalen? In fase 2 wordt naar antwoorden op dit soort vragen gezocht. SURFnet heeft hiervoor een gestandaardiseerd mechanisme.

Meer informatie

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