Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected writing of SATOSA

...

  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 SaToSaSATOSA
  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 to SATOSA (almost invisible to the user)
  5. The user is directed to his/her IdP/institution (can be via SURFconext, which would be transparent for the user, can be eduGAIN or an IdP connected to SaToSa to SATOSA directly)
  6. After successful authentication at the IdP, the user is redirected back to SaToSaSATOSA, with her their attributes. If authentication is via SURFconext, SURFconext is using an Attribute Release Policy (ARP) to only release R&S-attributes to SaToSa to SATOSA
  7. SaToSa uses SATOSA uses a combination of attributes that uniquely identify the user and SP entityID to gather supplementary CO specific COManage COmanage attributes and injects them into the SAML flow, while removing the original IdP attributes. If the identifying attributes are not supplied, SaToSa  SATOSA will send an empty assertion.
  8. If the IdP has provided identifying attributes, SaToSa  SATOSA searches a database the SCZ component COmanage has provisioned and uses them together with the entityID of the service to find the CO and CO-specific attributes.
  9. SaToSa can SATOSA can be configured to show a an Inform screen. If so configured, an inform is shown, telling the user she is leaving the boundaries of the institution explaining the (legal) consequences of this action.
  10. The user can only choose to completely grant or deny continuation to the service. There is no middle road on a per-attribute basis. If the user chooses to deny access, the flow stops here.
  11. If consent was given (or configured not to be required) SaToSa  SATOSA will send the SP/CO specific 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.

More info about the technical components and their relations that make up the SCZ environment can be found on Technical overview of SCZ .