This page is about a service, offered by SURF, 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!
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:
Invite your collaborators: as soon as someone accepts the invitation, accounts get created automatically for all connected services.
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.
Work with people from all over the world, either through their institutional account or one of the available guest identity providers SRAM offers.
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.
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.
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.
Here we share the 'user stories' (in broad outline) collected when we started developing SRAM.
Open Access and access regulation mechanisms often go together. Possible scenario's:
Schematically SRAM can be drawn as follows:
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).
Provides a solution to securely access (web and) non-web services.
Wondering how a flow of inviting a user to access via SSH looks like? See the below video, but know this is just to get an idea as the environment is developing continuously (if the video doesn't start playing, try opening it full-screen via the icon in the top right corner. The cow-sound at the start of the video is related to the name of the company involved in work on COmanage, Spherical Cow Group of which the name is based on the usage of spherical cow, a humorous metaphor for highly simplified scientific models of complex real life phenomena):
Another way of logging in is shown in a video at the bottom of PAM Module. We've made a connection to Azure AD VM's which we show in this video.
You can also try a demo yourself.
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).
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 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 .
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:
UK JISC has created a video about federated identity:
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.
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:
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).
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
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