...

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. De Science Collaboration Zone (SCZ, FIAM voor samenwerkende onderzoekers) probeert een aantal zaken op gebied van authenticatie, autorisatie en policies op te lossen. 

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 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 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 Asssurance' 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.

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

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

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.
• pyFF
  Voor metadata handling en de WAYF
• CMService
  Voor de Consent
• 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 mensen 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 die SURF heeft 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 het SCZ-project wordt gekeken of het gebruik van containers voordelen biedt op gebied van bijvoorbeeld schaalbaarheid, beheer, stabiliteit, beschikbaarheid etc.

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.

Meer informatie

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

This page is about a service, in development at SURF (production slated for Q3 2020), that makes it easier for research collaborations to set up and manage access to (data and compute) services they need for their projects. Using our service enables collaborations to spent more time on research instead of managing infrastructure. Everybody involved benefits: researchers, providers of services for researchers and institutions. Anybody is invited to read about the service, but the service is geared towards Dutch led research projects .

Don't want to read the information below but want to know how this can help you? Or have questions? You can send us an email and we'll set up a call!

Why this service?

Research is more and more about collaboration, also confirmed in the Dutch NWO 2019-2022-strategy. Researchers that want to collaborate (internationally) and parties that want to offer research facilities to collaborative organisations therefor face the question: how to provide secure access to resources? Researchers have typical access needs that aren't taken care of by the current solutions, and they have documented them in FIM4R-documents (Federated Identity Management for Research). People from around the world have been thinking about how to solve the access issues. In the European AARC-project (Authentication and Authorisation for Research and Collaboration) the specific identity and access challenges researchers face are addressed, and they made a clear video about the problem:

AARC crafted a blueprint architecture that addressed those challenges. SURF has followed up that development with a project (SCZ, Science Collaboration Zone), to develop a service based on the gained insights: SURF Research Access Management, SRAM. SRAM enables you to:

1. Simply create a group (CO, team) in our Membership Management Service.
   
2. Choose and connect the services you need for your collaboration.

3. Invite your collaborators: as soon as someone accepts the invitation, accounts get created automatically for all connected services.
   

4. Easily manage your group: adding or removing a member adds or inactivates accounts in connected services, so only allowed people have access and resources and data are secure and not misused.

5. Connect to web and 'non-web' services (think of resources accessed via SSH or WebDAV ): with SRAM those can be tied to institutional accounts, improving access revocation.

6. Work with people from all over the world, either through their institutional account or one of the available guest identity providers SRAM offers.

7. Simply manage authorization. Group membership in SRAM  is converted to attributes that can be used by the connected services to decide who can do what.
   

8. Improve your security by providing step-up authentication (two-factor etc)

No more need for zero hours (nul-uren) accounts that take forever to arrange for and stay in existence far too long and often incur unnessary cost (for licenses for example). Currently, for every new research project the access-wheel is reinvented. Collaborations and research are delayed in the start-up phase because setting up secure access takes time (and IT-expertise). What if there was a plug and play service? SRAM is delivering just that.

SRAM provides an access Authentication & Authorisation Infrastructure-as-a-Service focused on the needs of researchers, research projects and providers of resources for researchers. It takes care of user management. On these pages we describe what SRAM is about. 

Besides SRAM, which is tailored for Dutch-led research projects, similar AARC-based initiatives exist, like the EOSC-Life AAI and eduTEAMS.

How does SRAM provide a solution?

• on the SRAM website researchers can create a collaboration, manage membership, connect services etc.
• SRAM offers a tool to put the collaboration in control, while allowing others involved enough control as well, while everyone saves time. Who better knows who needs to be in (and out) of the collaboration at what moment? What services everyone needs to use for the research? What everyone should be allowed to do in connected services? Instead of a PI having to email with many people to allow or revoke access, zero hours contracts, many hours wasted on managing access instead of doing research: use SRAM.
• allowing guests from other institutions access to a resource nowadays often leads to just creating temporary accounts in one or more places. SRAM leverages institutional accounts and the existing global educational federated identity landscape. This improves data security (GDPR!), as access is revoked much faster. We're reusing the global institutional account 'telephone book', eduGAIN, so almost everyone with an institutional account can sign in.
  
• institutional accounts also offer better identity assurance: institutions check the identity of their researchers. So when someone logs in using their institutional account, everyone has a high level of confidence this is the intended person.
  
• we offer people that for any reason can't use an institutional account, like from a company, guest identity providers so they can use that to sign in and collaborate.
• we offer mechanisms that, together with federated identity, revokes access to data and resources as soon as possible. While nowadays, people often have access far to long, amongst others because no federated identity is used.

• providers of services for researcher also save time because they technically have to connect their services to SRAM only once (using open standards like LDAP, OIDC and SAML) and thereafter can easily offer their service to unlimited collaborations and people. Providers can configure and offload simple repetitive fault sensitive user creation tasks, while still being in control over which collaborations are are allowed access etc.
  

• institutions can decide how their researchers use SRAM, and are offered more insight in research collaborations their researchers are involved in. Institutions only have to connect (their identity management system, IdP) to SRAM once in order to give all its researchers (via one or more collaborations) access to SRAM. Actual access to participating services and resources is managed by the respective services (without approval of one or more service providers, users of SRAM can't use services) . Institutions can use granular authorisation options like authorisation rules and groups (as described in this blog) to limit who can access SRAM with their institutional account, and for instance have their research support office or data competence center create CO's etc
• we make it easier for service providers to allow people from outside of the Netherlands to access resources.

Here we share the 'user stories' (in broad outline) collected when we started developing SRAM.

SRAM and Open Access / Open data

Open Access and access regulation mechanisms often go together. Possible scenario's:

• The research team has every intention to publish lots of data and results at some point, but at the start or during the research, access has to be limited. SRAM can provide for this.
• Certain data is available for open access, but for all kinds of reasons, certain other data is only available for authorised users (see for instance page 75, 13.2 and 13.4, in 'RDM Toolkit'). SRAM can provide for that as well. 

Schematic overview of SRAM

Schematically SRAM can be drawn as follows:

Image AddedImage Added

The picture above shows that the research services are linked to SRAM: these services only have to make and maintain one link to service all Dutch led research collaborations that use SRAM to manage access. The picture shows the features of SRAM:

• Connects with eduGAIN so that research services are accessible for researchers at institutions outside the Netherlands.

• Provides a mechanism (via a 'membership management service, like COmanage, Hexaa, Perun or SBS) to invite users and manage groups and attributes.

• Provides a solution for people without an edu account to use services (guest providers in the Identity HUB, such as via ORCID, eIDAS, social accounts like from Microsoft and Google etc).

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

• Provides a solution to securely access (web and) non-web services.

Video and demo you can try yourself

A way of logging in is shown in a video at the bottom of PAM Module. We've also made a connection to Azure AD VM's which we show in this video.

How SRAM aligns with GDPR/privacy

Many federated academic services require a few user attributes to successfully complete login, usually name, email, and a persistent user identifier (called the “R&S attribute bundle”). An international program called the Research & Scholarship Entity Category (R&S) was established to meet this need. This program enables federated services serving a research or scholarly purpose to request that their national R&E federation (as InCommon is for the US) “tag” them with the R&S entity category. It also specifies how R&E federation operators vet such requests to ensure that such tags are only applied to appropriate services.

The R&S program further provides a means by which an academic IdP can automatically release the R&S attribute bundle when users login to services that have been tagged R&S, and a corresponding R&S tag to be given to an IdP to signal that it participates in this global program. This is important because some R&S tagged services will only permit a login to proceed if the user’s IdP is also tagged R&S.

It’s worth noting that releasing R&S attributes under the R&S program contributes to good privacy practice under the European General Data Protection Regulation (GDPR). REFEDS, the international organization of Research and Education Federations, conducted a thorough analysis of how attribute release under the R&S Category addresses GDPR requirements to arrive at this conclusion. 

SCZ only connects services in the R&S category. So IdP's can connect to our proxy, knowing they are compliant to the GDPR in regards to authentication (for processing personally identifiable information (PII) in services connected to our hub, the involved institutions might need extra contractual agreements, which normally are taken care of in the startup phase of research project).

Involved collaborations and institutions

We have a https://wiki.surfnet.nl/display/SCZ/Pilot+partners listing (a part of) the institutions piloting within our project and what is being piloted.

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.

Apart from pilots, we also frequently present about the project, like for the Health-RI event of Dec 8th 2017, where a poster was crafted to show the value of COmanage for collaborations like BBMRI. A generic version:

Which technical components are used?

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

Connecting services

Connecting Services to the SCZ environment describes how to services to the SCZ infrastructure. A list of connected services can be found at https://mdq.pilot.scz.lab.surf.nl/role/sp.html .

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 access a service, they are automatically forwarded to the login screen of their institution (or other organisation 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 organisation 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 institutional password and do not have 'another' account and password to manage
  • Users only have to enter their password on the institutional-login screen known to them (the fewer deviating screens ask for passwords, the less sensitive users are for phishing)
• It ensures user-friendliness
  • Users don't need to manage extra user accounts and passwords, they can re-use the already known institutional account 

UK JISC has created a video about federated identity:

Image Added

The European AARC-project has a training-module on what a identity federation is and what its advantages are: 1. AAI Overview.pdf. More information can be found at these websites: Federation-101 and Training for service providers. See also the advantages for IdP's, SP's and users as listed for SURFconext.

Why institutions need to connect

The SCZ can work without institutions releasing attributes; the researcher can use social accounts etc to sign in to the SCZ. But the value for all parties increases when an institution connects its IdP to a service in the SURFconext dashboard; this makes it so the researcher can use the credentials of their home institution, which provides more certainty for the research group and resource providers.

In many Dutch institutions it takes a long time between the request from a researcher to be able to sign in to a research resource with their institutional account and the time sign in is enabled. Sometimes it never happens. Often, the researcher doesn't want to wait that long, and chooses a different solution to get access, which often turns out to be less secure, more costly etc in the long run.

The reason why it often takes that long, is that the employees tasked with connecting a service, want to make sure privacy is protected, IPR is taken care of, whether any financial flows need to be available, whether usage of the service will increase helpdesk calls etc.

Some institutions have decided researchers can carry part of the mentioned responsibility. They have started using a 'light' procedure for connecting research services:

• The University of Amsterdam (UvA) is using a SURFconext feature, Autorisatieregels, to control who can access research services. You can read more about how the UvA is doing this on this Dutch language blog.
• The University of Utrecht is one of those institutions. On https://www.surf.nl/kennisbank/2018/best-practice-toegang-tot-nieuwe-diensten-hoeft-niet-altijd-lang-te-duren.html we've documented their way of working. Another

Will this be a SURF service?

SURF has conducted pilots to also answer this question. In May 2019 representatives of institutions advised/voted to develop SCZ into a production ready service. Our team is working on that, and we hope we will have a production ready service in the 1st half of 2020.

Due to our international relations and activities, we know GÉANT has been gearing up a new service, eduTEAMS. Both our teams have been sharing a lot of knowledge, and there are a lot of similarities. We intend to use eduTEAMS as part of our service offering to Dutch research collaborations. A nice feature is eduTEAMS also offers Hexaa and Perun as alternative Membership Management Services to COmanage (GÉANT has a comparison of the 3 systems).

Mailinglist

We have a mailing list for this project. Feel free to sign up for that list via https://list.surfnet.nl/mailman/listinfo/projectscz-fiam . An archive of previously shared messages can be found via https://list.surfnet.nl/mailman/private/projectscz-fiam . Interested? Questions? Suggestions? Mail with Raoul Teeuwen ( raoul.teeuwen@surfnet.nl ). 

If you find the SURFnet SCZ mailinglist interesting, you might also be interested in the following:

"Following some community interest, a new (not COmanage specific) list has been established: cmp-discuss. This is a discussion group for any technologies, policies, or use cases associated with collaboration management platforms, and especially general (non-product specific) topics or topics crossing multiple technologies.

You can join and manage your subscription here: https://groups.google.com/forum/#!aboutgroup/cmp-discuss

(The list was set up as a Google Group to avoid associations with any particular project or community.)"

Planning / timeline / status

In June 2017 phase 1 of the project was completed. Phase 2 ended in May 2019 with institutions advising to develop the result of project SCZ to a production ready service. In phase 1, use cases were drawn up and coordinated with a number of cooperative organisations, an architecture was drawn up and needs were assessed. In phase 2 was dedicated to realising the various components and gaining experience through pilots. 

SCZ phase 3 focuses on creating a production ready services, which includes deciding on a software stack, setting up that stack, contracting sub contractors, having experts conduct code audits/penetration tests, draft relevant contract texts/AUPs etc, design and implement support processes etc

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
• Dec 2017 - Jun 2019 - Pilot with the pilot environment:
  • Access for "ordinary" (pilot) users
  • Finetuning flows
  • Connect more services
  • Develop the platform
• Jun 2019 - mid 2020 - SCZ phase 3 (service development)

Support

• Support questions and emails can be directed to scz-support@surfnet.nl .
• Want to save a URL that will 'always' bring you to the best SRAM SCZ info? Use this short URL:  https://edu.nl/sram . If at some point this wiki gets replaced by another URL, we'll make sure that short URL will bring you to the new page!

More information