This page shows the steps a user goes through when accessing a service connected to the SCZ-environment:

  1. A user visits the URL of a service (like a wiki) and clicks a link to authenticate via SCZ
  2. The (browser of the) user is (automatically) directed to the SCZ component SaToSa
  3. If necessary, a Where-Are-You-From-screen is presented so the user can select the IdP where he/she wants to authenticate
  4. After the optional WAYF, the user is directed back to SaToSa
  5. The user is directed to his/her institution (can be via SURFconext, which would be transparent for the user, can be eduGAIN or an IdP connected to SaToSa directly)
  6. After successful authentication at the IdP, the user is redirected back to SaToSa, with it’s attributes. If authentication is via SURFconext, SURFconext is using an Attribute Release Policy (ARP) to only release R&S-attributes to SaToSa
  7. SaToSa checks for the EPPN-attribute. If this attribute is not supplied, SaToSa redirects the user to the service, supplying the service with attributes it received from the IdP. And the flow ‘stops’ at this point. Whether the service is able to operate with the supplied attributes is not something SCZ can decide.
  8. If the IdP has provided an EPPN, SaToSa contacts the SCZ component COmanage (which, for SaToSa, is just another SP) and supplies EPPN and entity id of the service the user tries to access. COmanage checks whether the supplied EPPN can be found. If found, COmanage returns attributes detailing to what CO’s the user belongs, and any additional attributes belonging to the CO(‘s) the user is member of. Only attributes necessary for the visited service will be returned to SaToSa.
  9. SaToSa can be configured to show a Consent form. If so configured, a consent form is shown
  10. Whether or not the user consents is returned to SaToSa
  11. If consent was given (or configured not to be required) SaToSa combines the attributes received from the IdP and from COmanage and supplies the attributes to the service.
  12. Based on the internal of the service (like required attributes and whether they are supplied), the user does or does not get access to the service.