Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

Schematisch zien we de SCZ momenteel als volgt voor ons:

Image Modified

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 Het bovenstaande plaatje toont dat de onderzoeksdiensten met de SCZ-proxy worden gekoppeld: die diensten hoeven dus maar 1 koppeling te maken en onderhouden. De SCZ-proxyHet plaatje toont de features van de SCZ :

  • koppelt aan de andere kant met SURFconext zodat onderzoekers bij Nederlandse instellingen via SURFconext gebruik kunnen maken van de onderzoeksdiensten
  • biedt een mogelijkheid 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 om gebruikers uit te nodigen en groepen en attributen te beheren 
  • zorgt voor een oplossing om non-web-diensten federatief te ontsluiten

...

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?

...

  • 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' meest pragmatische oplossing voor bieden.
  • Containerization
    Binnen SCZ wordt gekeken of het gebruik van containers voordelen biedt op gebied van bijvoorbeeld schaalbaarheid, beheer, stabiliteit, beschikbaarheid etc

...

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

...