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 ):
In case you're not sure about these questions, please contact the SCZ-team, for instance firstname.lastname@example.org .
Followed technical standards
The SCZ solution adheres to/plans to adhere to 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).
- Status: planned
Technical and Policy part
Connecting a service to the SCZ-environment 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:
- 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 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 like
- 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
- services to comply to the Research and Scholarship Entity Category
- services to comply with and use Sirtfi
- services to comply to the REFEDS Assurance Framework
- SCZ will check for certain things:
- the service to use a SSL certificate: 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 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).
Some points of attention
- Attributes are not passed from the IdP of the user 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 SP
- Before you receive attributes, at least the following needs to be catered for:
- the SP needs to be connected to the SCZ
- the IdP of the user needs to be connected to the SCZ
- for Dutch IdP's, that means the SURFconext contactperson of the institution needs to connect their IdP to SCZ in the SURFconext dashboard
- for eduGAIN:
- 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 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 email@example.com .