Before you can use a research service, both a (one time) 'technical' connection between SRAM and a service is necessary, as well as a 'logical' connection between the collaboration the collaboration and the service:

• A technical connection means the manager of the service has worked with SURF so 'bits can flow' from SRAM to the service (and back).
• Once this is taken care of, any collaboration any collaboration can select a service in SRAM and request a 'logical' connection. Once approved (depending on configuration, this can be immediately), accounts for members of the collaboration the collaboration will be created and managed automatically in the service.
• You're always in control of which collaborations which collaborations you allow access.

We'll connect any service that seems to be geared towards researchers, and for which, after a talk, it seems a great idea to connect to SRAM. In some cases it's pretty clear a service is geared towards researchers. In other cases, there is a grey area. For instance: we know researchers often use virtual machines, which they love to spin up in clouds, as clouds offer great value, flexibility etc. So yes, we'll connect such clouds. But often, connecting such a cloud also opens up access to more generic services.

Users on SRAM can only access a service if an admin decides to connect such a service to the collaboration, and invites the user to the collaboration. We assume the admin is the one that knows what services are needed for the research collaboration, who to allow access to the research collaboration, what to inform users about relating to what they are allowed to and what happens with their data.

Basic checks

SRAM is great, but not the best solution for every situation. Some basic questions you might want to think about before you you contact us.

• If the service you want connected is is
  • web/browser based: does it already have support for federated authentication protocols such as SAML or OIDC? If not: is there anybody willing and able to change (and maintain) the application/service so it is able to handle a SAML or OIDC connection? 
  • a non-web service: SRAM will provision an LDAP under your control. Does your application already use an LDAP?
• What users need to access the service?
  • Only people from the Netherlands? Or also from other parts other parts of the world?
  • Only people with an educational account, or also people without such an account, like from companies etc?
  • Did or will the home organisation of the potential users connect their IdP to SRAM? (could be important, but users can always use a guest IdP).
• Do you actually need SRAM, or does SURFconext also supply what you want? SURFconext offers federated authentication for browser based services, teams, authorization rules, SURFsecureID (step up/strong authentication), guest users etc.

Protocols

SRAM adheres to the following standards:

• SAML 2.0 (as implemented by SURF in SURFconext)
  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect (preferred in accordance to to SAML2int profile)
  • urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST (can only be used in case your software doesn't support HTTP-Redirect)
• OpenID Connect (for Service Providers). 
• LDAP.
• SCIM.

We're happy to talk to you in any case if you're interested in connecting your service. What is needed on the technical side depends on your situation. We have documented some common ways of connecting your service to SRAM, using SAML, OIDC or LDAP. On that page you'll also find attributes we releaseAnd also documented the attributes SRAM releases.

Groups, authorisation

SRAM offers collaborations offers collaborations to organise members into groups. Group information will be passed to the research services when a user authenticates and accesses your service. Group information can for instance be used to decide on authorization, so which users are allowed access to what. You would need to map group information to whatever action you want.

...

We advise admins to check whether a service complies (so as a service owner, you might want to check these out):

1. to the Research and Scholarship Entity Category (R&S)
2. to the GÉANT GÉANT Data Protection Code of Conduct  ("CoCo"), with the intend to comply with with v2 GDPR version of the Code of Conduct
3. with and use use Sirtfi
4. to the to the REFEDS Assurance Framework

Configuring how collaborations how collaborations can connect

You need to let us know know whether any collaboration any collaboration is allowed to connect without your approval, or whether you want to be emailed when a collaboration a collaboration wants to use your service.