This page contains information on the SURF Research Access Management (SRAM) service, but focused on providers of research services. Generic information about SRAM can be found at SRAM documentation .
- you need to technically connect your service to SRAM. Most used protocols are SAML, OIDC and LDAP. We will work with you to connect your service!
- once connected technically, you can decide whether every CO can use your service without your explicit manual approval, or whether you want to be informed as soon as a CO wants to use your service so you can manually approve (or not)
- you're always in control of which CO's you allow access
- any questions? Contact the SRAM-team at firstname.lastname@example.org
The rest of this page deals with:
Connecting: technical and logical
Before research collaborations can use your research resource, both a 'technical' connection between SRAM and your service is necessary, as well as a 'logical' connection between the SRAM CO and the service:
- a technical connection means 'bits can flow' from SRAM to the service (and back). Most of the time, you'll do this only once
- once this is taken care of, any CO 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 CO will be created and managed automatically in the service
SRAM is great, but not the best solution for every situation. Some basic questions you might want to think about before contacting us (please do contact us, we will help ):
If the service you want connected 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 of the world?
- Only people with an educational account, or also people without such an account?
- Will the home organization of the potential users connect their IdP to SRAM?
- 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.
In case you're not sure about these questions, please contact the SRAM-team.
Followed technical standards
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 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).
Technical connection: protocols / flavors
In principal, we're happy to talk to you in any case if you're interested in connecting your service.
Over time, we're building up experience with certain situations. What is needed on the technical side depends on your situation. We have documented some common situations and relevant information:
- Connect to SRAM using
- Information on supplied attributes can be found here.
- Information on how we combine SSH-login with authentication in a web browser via a PAM module can be found here.
Contact us if you're ready or interested in connecting your platform.
SRAM does check for certain things:
- whether the service uses secure communications. For instance, when a SSL certificate is used, as a rule of thumb, it should have at least a "B" rating on SSLLabs.com (but preferably better, of course). If you would like to test your server for configuration issues, you can use the Qualys SSL labs server test at: https://www.ssllabs.com/ssltest/ .
SRAM offers CO's to organize CO-members into groups. Group information will be passed to the research services when a user authenticates. Group information can for instance be used to decide on authorization, so which users are allowed access to what.
During service development, we had discussions about whether SRAM should 'demand' certain things from research services before they are allowed to connect, and if so, to what. But who are we to decide what a research collaboration deems o.k.? So for now we decided to limit the 'demands', but stick to 'advise'.
We do advise CO's to check whether a service complies:
- to the Research and Scholarship Entity Category (R&S)
- to the GÉANT Data Protection Code of Conduct ("CoCo"), with the intend to comply with v2 GDPR version of the Code of Conduct
- with and use Sirtfi
- to the REFEDS Assurance Framework
So, as a service supplier, we encourage you to look into those, and contact us if you have any questions!
Configuring how CO's can connect
You need to let us know:
- whether any CO is allowed to connect, or whether you want to be emailed when a CO requests access
In due time, we hope to offer a fancy dashboard for you to configure your service. For now, we will use email to agree on your configuration.
Before you receive attributes, at least the following needs to be catered for:
- your SP needs to be connected to SRAM
- the IdP the user wants to use to authenticate, needs to be connected to SRAM
- in SRAM
- a CO needs to connect your service
- the user needs to be invited to the CO, accept the invite and successfully enroll
in case you want to use group information, groups need to be created and people assigned to groups
Any questions? Contact the SRAM-team at email@example.com .