This page is about a service, offered by SURFin 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!

...

Video and demo you can try yourself

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

...

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

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.

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 

...

• 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

• 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