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 24 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 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. We hebben het dan over Authenticatie, Autorisatie en policies die van toepassing zijn:

  • Er moet 'iets' geregeld worden om mensen uit te nodigen die toegang moeten hebben tot resources (invites, enrollment),
  • Het daadwerkelijk federatief toegang geven van uitgenodigde mensen tot (vooral non-web-)resources (denk aan resources die via SSH benaderd moeten worden) kost nu vaak relatief veel tijd ('accountbeheer', provisioning etc),
  • Toegang geven tot een dienst aan niet-Nederlandse onderzoekers (via publicatie in eduGAIN) en mensen zonder edu-account ("gasten", 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 moeten kunnen worden voor het autoriseren van gebruikers.(de benodigde attributen worden niet standaard door instellingen worden geleverd omdat ze 'onderzoeksgroep-specifiek' zijn)
  • Bestaande structuren hebben beperkingen. SURFconext-voorbeeld: bij elke instelling zit een verantwoordelijke die per dienst afweegt of die wel of niet via SURFconext beschikbaar gemaakt moet worden, en o.a. regelgeving zorgt dat dat bij veel instellingen niet of traag gebeurt indien er "slechts enkele onderzoekers" toegang moeten hebben.
  • (geen geverifieerde accounts, geen standaard workflows, geen herbruikbare oplossingen, geen audit trail om er een paar te noemen, geen mogelijkheid om zaken te delegeren)

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:

  • 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 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 (of is dit nog iets te vroeg om te zeggen).
  • Te zorgen voor een mogelijkheid om specifieke attributen te beheren per samenwerkingsgroep
  • Een (1) SCZ-omgeving te bieden waar veel diensten die voor onderzoekers relevant zijn aan gekoppeld zijn. Een instelling hoeft eenmalig met de SCZ te koppelen om daarmee onderzoekers toegang te geven tot alle deelnemende diensten en resources.
  • Te zorgen dat instellingen die resources willen delen dat kunnen doen met de SCZ, en dat de SCZ zorgt voor eenvoudige beschikbaarheid via eduGAIN (opmerking Gerben: ik neem aan dat we willen filteren op attributen als: coco, sirtify, etc. Zo ja, willen daar dan nog iets over vermelden)
  • Te zorgen dat non-web resources via instellings-accounts (federatief) benaderbaar worden

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

Schematisch zien we de SCZ momenteel als volgt voor ons:

Bij dit plaatje hoort uiteraard een verhaal en je kunt er lang over praten en veel over zeggen. Veel tekst lijkt ons in deze wiki niet handig. In het kort worden onderzoeksdiensten met de SCZ-proxy gekoppeld: die diensten hoeven dus maar 1 koppeling te maken en onderhouden. De SCZ-proxy:

  • koppelt aan de andere kant met SURFconext zodat onderzoekers bij Nederlandse instellingen gebruik kunnen maken van de onderzoeksdiensten en zodat gebruik kan worden gemaakt van de gast-IdP (OneGini) (edit Paul: waarschijnlijk gaan we dat in SCZ anders doen) die SURFconext al heeft ingeregeld
  • koppelt met eduGAIN zodat onderzoekers bij instellingen buiten Nederland de onderzoeksdiensten kunnen gebruiken
  • zorgt voor een mechanisme om gebruikers uit te nodigen en groepen en attributen te beheren 
  • zorgt voor een oplossing om non-web-diensten federatief te ontsluiten

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:

  • 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 (o.a.) UvA/HvA, BBMRI (UMCs) en U2Connect (iRODS)

Planning

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

Wat verwachten we van deelnemende instellingen?

We verwachten vooral input over wat we moeten bouwen en dat ze hun gebruikers/samenwerkingen actief betrekken. De deelnemende instellingen gaan tussen oktober 2017 en mei 2018 testen of wat er gerealiseerd is, voor hun use case(s) voldoet. 

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:

  • 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 (APS), public ssh/pgp keys, gridcertificaten etc opgeslagen
  • 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 (zoals 'alleen via SSH toegankelijke machines')
    Voor HTML gebaseerde webdiensten kan relatief eenvoudig via b.v. het SAML- of OIDC-protocol worden geregeld dat je daar met je instellings-account federatief op kunt inloggen. Veel resources gebruiken echter niet het HTML-protocol. Het benaderen van servers via SSH is daar een voorbeeld van. SSH is een oud protocol waar SAML en OIDC niet mee samen kunnen werken. Er is al vaak gekeken naar manieren om de toegang tot en beheer van zulke 'non web'-bronnen federatief te regelen. SCZ gaat de hier momenteel 'beste' oplossing voor bieden.
  • 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)

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

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

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:

  • Als dienst/resource heb je zekerheid over de identiteit, zonder dat je zelf iemand met zijn/haar paspoort langs je loket hoeft te laten komen 
  • Als dienst/resource hoef je je niet/minder meer druk te maken om het proces van aanmaken van een account, geen gebruikers te ondersteunen die hun wachtwoord vergeten etc
  • Gebruikers hebben niet 'nog' een account en wachtwoord om te managen
  • Gebruikers zijn eerder geneigd om één sterk wachtwoord te onthouden
  • Gerbruikers zullen het instellingswachtwoord niet gebruiken voor diensten
  • Als dienst/resource heb je meer controle over toegang tot de dienst wanneer mensen van baan veranderen: het account bij hun 'home' organisatie wordt dan onbruikbaar gemaakt, en ze kunnen dat dus niet meer gebruiken om op 'jouw' dienst/resource in te loggen
  • Met hoe minder verschillende inlogschermen een gebruiker te maken heeft, hoe minder gevoelig hij/zij wordt voor phishing

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.

Meer informatie

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

 

  • No labels