Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 50 Next »

LET OP

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

Deze pagina is voor mensen die meer willen weten over de Science Collaboration Zone (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 op welke manier  deze technische oplossingen door SURF als dienst kan worden aangeboden.

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:

  • Er moet 'iets' geregeld worden om mensen uit te nodigen die toegang moeten hebben tot resources (invites, enrollment),
  • Het daadwerkelijk -op basis van federatieve authenticatie- toegang geven van uitgenodigde mensen tot resources (denk aan resources die via SSH of webDAV ontsloten worden) kost nu vaak relatief veel tijd ('accountbeheer', provisioning etc),
  • Toegang geven tot een dienst aan niet-Nederlandse onderzoekers en mensen zonder edu-account (b.v. van bedrijven die betrokken zijn bij het onderzoek) vergt relatief veel werk,
  • Er moet elke keer 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 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?

De Science Collaboration Zone wil 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 daarmee al haar onderzoekers (via een of meerdere samenwerkingen) toegang te geven tot de deelnemende diensten en resources van hun samenwerkingen

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

  • koppelt 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 behoeften gepeild. Fase 2 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 middels pilot projecten met
  • 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 delen/geven en nieuwe features en requirements definieren en zo samen met SURFnet 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.
  • 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 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 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 SCZ wordt gekeken of het gebruik van containers voordelen biedt op gebied van bijvoorbeeld schaalbaarheid, beheer, stabiliteit, beschikbaarheid etc

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:

  • 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)

Wordt dit een dienst van SURF?

In deze fase 2 kijkt SURF of en hoe de SCZ als een dienst aangeboden kan worden. Vragen die daarbij spelen zijn: 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 mechanismeIn de zomer van 2018 zullen we op basis van de ervaringen uit de pilots een beslissing hierover nemen. 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 ).

 

  • No labels