This is the home of the Science Collaboration Zone space. Our intro is in Dutch. If you think it should be in English, send an email to Raoul Teeuwen (raoul.teeuwen@surfnet.nl).

...

Researchers who want to collaborate (internationally) and providers of resources who want to offer research facilities to collaborative organisations often face questions related to providing access to resources. It takes valuable time and resources to set up systems to control access and to connect services. The Science Collaboration Zone (SCZ,

...

 FIAM for collaborating researchers ) tries to solve a number of issues in the field of authentication, authorization and policies.

This page is for people who want to know more about the infrastructure the SCZ-project is trying build & pilot. The SCZ is currently being developed by SURF on the basis of use cases and scenarios from a number of institutions. The project also examines whether and, if so, how the SCZ can be offered by SURF as a service.

SURF is collaborating in this project with Dutch institutions, but the general solution is usable in any country. 

Why the SCZ project?

There are a number of specific problems for collaboration between researchers, which we will try to solve with the SCZ:

• Something has to be arranged to invite people who need access to resources (invites, enrollment). Often there is a need to manage collaboration groups (membership etc).

• Providing access to invited people to the actual resources currently often takes a relatively long time (need for setting up 'account management', provisioning etc). In addition to web-based services, this also explicitly concerns non-web services for which there are currently no possibilities for federated authentication (think of resources accessed via SSH or WebDAV ).

• Giving access to a service to non-Dutch researchers and people without an institutional account (eg from companies involved in the research) requires a relatively large amount of work.

• Group membership can be used to decide on authorization: what is a user allowed to do within a certain service? This requires a solution that can convert the group information into attributes that are subsequently consumed and interpreted by the resources to be shared (eg wikis, compute or data) for authorizing users.

Currently, for every new research the wheel is reinvented to arrange for the things mentioned. Collaborations are delayed in the start-up phase because providing access takes time. The Science Collaboration Zone wants to offer a "as a service"-solution for authentication and authorization.

How does SCZ provide a solution?

In the Science Collaboration Zone project, we want to offer a solution:

• To ensure that parties who want to share resources can do so by simple connecting the resource to the SCZ proxy. The SCZ solution takes care, amongst others, of making the service available via eduGAIN.

• Ensure that non-web resources like SSH and WebDav can be approached via federated authentication (eg institutional account) (for the benefits of federated authentication see " Why federative"? ).

• Provide an environment where institutions and cooperative organisations can quickly request a collaboration group, assign group managers and then manage that group themselves, invite people, etc.

• To provide a possibility to manage specific attributes per collaborative organisation.

• To ensure that people without an edu account can also easily be invited and access the resources, where possible with a higher 'Level of Assurance' than with a social identity.

• To ensure that an institution only has to join the SCZ once in order to give all its researchers (via one or more collaborations) access to the participating services and resources of their collaborations.

To get an extra idea of what SCZ wants to offer for the time being, here we share the 'user stories' (in broad outline) for which we want to offer a solution with SCZ.

Schematic overview of the SCZ solution 

Schematically the SCZ can be drawn as follows:

Image Added

The picture above shows that the research services are linked to the SCZ proxy: these services only have to make and maintain one link. The picture shows the features of the SCZ:

• Link with SURFconext so that researchers at Dutch institutions can make use of the research services via SURFconext.

• Provides a solution for people without an edu account to use services (such as via Google and / or other social accounts).

• Connects with eduGAIN so that researchers at institutions outside the Netherlands can use the research services.

• Provides a mechanism (via COmanage) to invite users and manage groups and attributes.

• Provides a solution to securely unlock non-web services.

Wondering how a flow of inviting a user to access via SSH looks like? 

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 Assurance' 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:

Image Removed

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.

Benieuwd hoe een flow van uitnodigen van een gebruiker tot toegang via SSH er dan uit ziet? Zie dan b.v. het filmpje onderin op See the video at the bottom of the End user documentation SCZ COmanage .

Planning / timeline / status

In juni June 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

phase 1 of the project was completed, and phase 2 started. In phase 1, use cases were drawn up and coordinated with a number of cooperative organizations, an architecture was drawn up and needs were assessed. Phase 2, which runs from now until the third quarter of 2018, is dedicated to realizing the various components and gaining experience through pilots.

SCZ phase 2 focuses on:

• Building a largest-commoner service for use cases and pilots.

• Building the SCZ technical infrastructure

• Drafting the SCZ policy.

• Testing the SCZ technical infrastructure and policy on the described use cases.

• Acquiring experience with the SCZ through pilot projects with institutions

• Drafting a business case.

Schedule

• Aug / Sep 2017 - Establish pilot environment
• Oct / Nov 2017 - Connecting backend systems
• Oct / Nov 2017 - Set up and test deployment flows
• Oct-Dec 2017 - Set up and fine-tune access for external people / guests / etc
• Oct 2017 - May 2018 - Pilot:
  • Access "ordinary" users
  • Finetuning flows
  • Connect more services
  • Develop a platform
• 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 phase 3 (dienstontwikkeling of gerealiseerde gecontroleerd afbouwen)
• Tot eind 2018 - Ongeacht besluit (go of nogo) worden pilot partners tot eind 2018 ondersteund.

Deelnemende instellingen

• service development or realized controlled phasing out)
• Until the end of 2018 - Regardless of the decision (go or nogo) pilot partners will be supported until the end of 2018.

Involved collaborations and institutions

The following institutions and parties have indicated that they want to participate in the pilot::De volgende instellingen en partijen hebben aangegeven mee te willen doen met de pilot:

• UvA/HvA
• BBMRI (UMCs). For the Health-RI event of Dec 8th 2017 a poster was crafted to show the value of COmanage for collaborations like BBMRI:
  

  View file
  name Enabling_collaborative_access_to_data_and_resources_in_health_research_ Federated_Identity_and_Access_Management.pdf height 250

• U2Connect (iRODS)
• CLARIAH
• Aeneas (Astron)

Partijen die interesse hebben getoond/waar contacten mee zijn in verband met de Parties that have shown an interest / have contacted SCZ: Deltares, TraIT / Lygature, TUe, Donders Institute, VUmc,  uTwenteuTwente / NLeScience City Cloud Project, AuthorE / TrustDocA / ErasmusMCErasmus MC, SURFsara (Research Cloud).

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?

Geinteresseerd in de gebruikte componenten? Zie Technical overview of SCZ.

Documentatie van COmanage

Benieuwd naar hoe u aan de slag kan in COmanage? Op End user documentation SCZ COmanage vindt u documentatie.

Diensten aansluiten

Op Connecting services to the SCZ-environment vindt u informatie over het aansluiten van diensten op COmanage.

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.

Mailinglist & meer informatie

The institutions involved in pilots are expected to participate in meetings and allow the right people within the institution to test the pilot environment, provide feedback to SURF and participate in talks about new features and requirements.

Interested or questions? See under ' More information '.

Which technical components are used?

Interested in the components used? See Technical overview or SCZ .

COmanage documentation

Curious about how you can get started in COmanage? We have organised and provide links to End user documentation SCZ COmanage .

Connecting services

On Connecting Services to the SCZ environment you will find information about connecting services to the SCZ infrastructure.

Why authenticate in a federated way?

Enabling a service / resource for federated authentication means users can 'login' (authenticate) with their institutional account: as soon as they want to acces a service, they are automatically forwarded to the login screen of their institution (or other organization where they have an account, if that can be used, such as a bank). Reasons to arrange this like this:

• It provides more reliability
  • As a service / resource you have certainty about the identity
  • If an employee leaves an organization and may therefore no longer have access to a service / resource, federative authentication ensures that access is no longer possible.
• It ensures scalability
  • As a service / resource you have no / less work on creating an account, supporting users who forget their password etc
• It increases security
  • Users can use their (strong) settings password and do not have 'another' account and password to manage
  • Users only have to enter their password on the settings-login screen known to them (the fewer deviating screens ask for passwords, the less sensitive users are for phishing)
• It ensures user-friendliness
  • With only 1 already existing and known username / password can use more services and no / less extra separate log-in data

Will this be a SURF service?

SURF is conducting pilots to also answer this question. In this way, after the pilots, we can draw conclusions about the functionalities: does the SCZ actually solve these problems? We also have a better idea of the feasability to offer this centrally and if so including the costs (in equipment and people) that are needed to offer such a central infrastructure. In the summer of 2018 we will decide on this based on the experiences with the pilots. Naturally, the pilot partners have considerable influence on this process. Should it be decided not to offer the SCZ as a service, we will enter into a phase-out process with each pilot partner, for example SURF can help transferring the infrastructure to a local copy an institution can run locally.

Mailinglist & more information

We have a mailing list for this project. An archive of previously shared messages can be found Voor dit project hebben we een mailinglist. Eerder op die mailinglijst gedeelde berichten zijn te vinden via https://list.surfnet.nl/mailman/private/projectscz-fiam . Meld je gerust aan voor die lijst  Feel free to sign up for that list via https://list.surfnet.nl/mailman/listinfo/projectscz-fiam . Interesse Interested? Vragen Ask? Suggesties Suggestions? Mail met with Raoul Teeuwen ( raoul.teeuwen@surfnet.nl ). 

...

More information in this wiki