Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

This page shows the steps a user goes through when accessing a service connected to the SCZ-environment (after initial sign-up with a CO in COmanage):

  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) redirected 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 her 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 via consent page, supplying the service with consented 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 searches a database the SCZ component COmanage has provisioned and uses EPPN and entity id of the service to find the CO and CO-specific attributes. Only attributes necessary for the visited service will be injected in the available assertion and returned by SaToSa.
  9. SaToSa can be configured to show a Consent form. If so configured, a consent form is shown
  10. Whether or not and for what attributes 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 internals of the service (like required attributes and whether they are supplied), the user does or does not get access to the service.
  • No labels