Versions Compared


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


Simplified: we provide an 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. The service name: SURF Research Access Management.

Table of Contents

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 addresses those challenges. SCZ is basically doing an implementation of that blueprint.

Why the SCZ project?

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). We address a number of those problems in the SCZ-project:


Currently, for every new research the wheel is reinvented to arrange for the things mentioned. Collaborations and research are delayed in the start-up phase because providing access takes time. What if there was a plug and play service?

How does SCZ provide a solution?

With the SCZ project, we:


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

SCZ 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. SCZ 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'. SCZ can provide for that as well. 

Schematic overview of the SCZ solution 

Schematically the SCZ can be drawn as follows:


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

  • Provides a mechanism (via COmanage) to invite users and manage groups and attributes (a so called 'Membership Management Service').

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

  • Link with SURFconext so that researchers at Dutch institutions can make use of the research services via SURFconext and the SCZ proxy.
  • Provides a solution to securely unlock non-web services.

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


You can also try a demo yourself.

How SCZ 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.


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 listing (a part of) the institutions piloting within our project and what is being piloted.


Interested in the components used? See Technical overview of 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

Connecting Services to the SCZ environment describes how to services to the SCZ infrastructure. A list of connected services can be found at .

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:


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.


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


We have a mailing list for this project. Feel free to sign up for that list via . An archive of previously shared messages can be found via . Interested? Questions? Suggestions? Mail with Raoul Teeuwen ( ). 


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


  • 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 questions and emails can be directed to .

More information

Children Display