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)):

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

Followed technical standards

The SCZ solution adheres to/plans to adhere to the following standards:

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:

  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 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
      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 will check for certain things:
      1. 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/ 
  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:

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

Questions?

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

Underlying pages