Some basic questions you might want to think about before contacting us (please do contact us, we will help ):
In case you're not sure about these questions, please contact the SRAM-team, for instance email@example.com .
Followed technical standards
SRAM uses the following standards:
- Status: implemented
- SAML 2.0 (as implemented by SURFnet 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).
We plan to use the following standards:
Technical and Policy part
Connecting a service to SRAM has a technical as well as policy aspect:
- We think research collaborations should decide what services they want to use. Therefor SRAM connects all research services that are or seem to be in demand. We do advise research collaborations to check out the AARC Policy Development Kit (MOOC), which provides templates of all kinds of policies like Acceptable Use Policy. The AARC Policy Development Kit points out research collaborations should check whether
- services comply to the GÉANT Data Protection Code of Conduct ("CoCo"), with the intend to comply with v2 GDPR version of the Code of Conduct
- services comply to the Research and Scholarship Entity Category
- services comply with and use Sirtfi
- services comply to the REFEDS Assurance Framework
- SRAM will check for certain things:
- the service to use a SSL certificate to secure the connection: 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/
- Technical: what is needed on the technical side depends on your situation. We have documented some common situations and relevant information in the child-pages of this page:
After the above technical connection has been taken care of, a CO can request access to a service in SRAM.
Some points of attention
- Attributes are not passed from the IdP of the user directly to the SP. SRAM stores user attributes whenever the user signs in to SRAM. SRAM will pass stored attributes tothe SP. Before a user can authenticate at your service and an SP receives attributes about a user, at least the following needs to be catered for:
- the service needs to be connected to SRAM
- in SRAM a CO needs to be created and a CO-admin needs to be enrolled
- the CO needs to connect to a service in SRAM. A service will only receive attributes from identities that are member of a CO that has opted to use the service
- a CO-member needs to sign into SRAM using an IdP connected to SRAM:
- for Dutch IdP's, that means the SURFconext contact person of the institution needs to connect their IdP to SRAM in the SURFconext dashboard
- people from non-Dutch IdP's can use eduGAIN to access SRAM:
- a user can use a SRAM guest IdP (like eduID)
See below in the underlying pages for specific cases, like for example with OIDC, you need to specifically request attributes.
When you can't find what you're looking for, please let us know via firstname.lastname@example.org .