Versions Compared

Key

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

Table of Contents

Basic checks

The SCZ 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 (wink)):

  • If the service you want connected to connect 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, SCZ 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? (we do support non-Dutch accounts)
    • Only people with an educational account, or also people without such an account? (we do provide a guest identity provider)
    • Will the home organisation of the potential users connect their IdP to the SCZSRAM?
  • Do you actually need the SCZSRAM, or does SURFconext also  also supply what you want? SURFconext offers federated authentication for browser based services, teams, authorisation rules, SURFsecureID (step up/strong authentication), guest users etc.

In case you're not sure about these questions, please contact the SCZSRAM-team, for instance raoul.teeuwen@surfnet.nl .

Followed technical standards

The SCZ solution adheres to/plans to adhere to 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). 
    • LDAP.
    Status: planned

We plan to use the following standards:

Technical and Policy part

Connecting a service to the SCZ-environment SRAM has a technical as well as policy aspect. During the pilot, we will be less strict on the policy part, but if the pilot leads to a Go and a production ready service will be built, it's important to realise the following policy is currently considered for services that want to connect:

  1. Policy. 
    1. We want to make CO's use the service they seem fit for use. If SCZ starts demanding services need to comply to certain standards before we connect a service, we could get a situation where CO's can't use a service they themselves deem fit to use. Therefor, currently, SCZ does connect services CO's and service providers want to have available. We do advise CO's 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 references links likepoints out research collaborations should check whether
      1. services to 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
      2. services to comply to the Research and Scholarship Entity Category
      3. services to comply with and use Sirtfi
      4. services to comply to the REFEDS Assurance Framework
    2. SCZ SRAM will check for certain things:
      1. 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/ 
  2. 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:
    Children Display

After the above technical connection has been taken care of, a service needs to be connected to a CO in our Membership Management Service (MMS, for example COmanage) before receiving attributes stored in the MMS (enter the entityID of the SP for "Service URL" and "Entitlement URI" for the CO that needs access to that SP and specify 'Zone Provisioner' as provisioning target).

...

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: the attributes received from the IdP are (partly) used for SCZ. SCZ will look up your account info in the MMS (COmanage) and use the attributes found internally to pass to the SP. So: while you might see attributes from the IdP, in case the configuration in SCZ/MMS isn't right, you might not receive attributes at the SPBefore you receive attributes. 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 SP service needs to be connected to the SCZthe IdP of the user needs to be connected to the SCZto 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 contactperson contact person of the institution needs to connect their IdP to SCZ SRAM in the SURFconext dashboard
      • for eduGAINpeople from non-Dutch IdP's can use eduGAIN to access SRAM:
    • in SCZ a CO needs to be created and a CO-admin needs to be enrolled
    • in SCZ a zone provisioner needs to be defined for your CO and SP
    • you will only receive attributes from identities that are member of your CO
    • the login proxy gets its data from a 'connection database' in which the CO attributes are provisioned. De relevant database table is updated whenever a new member is added to the CO while the ZoneProvisioner of the CO is set to  "automatic". To provision all attributes to existing members, that existed before the ZoneProvisioner was configured, the "reprovision all" button needs to be clicked
    • you need to set up groups within your CO, maybe COU's, and define an enrolment for your CO, so people can register.
    See the
      • 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.

Questions?

When you can't find what you're looking for, please let us know via raoul.teeuwen@surfnet.nl .

Underlying pages

Children Display