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 8 Next »

Wherever possible, proven technology is used. We build the SCZ infrastructure by thinking in functions. We analyse existing, often open source, components for fit for our purpose, and change code when necessary to have all components work together and deliver the functionality we need.

Architecture in 2 images

and one level deeper:



More info about the 'happy flow' for a user trying to access an SP while authenticating via the SCZ environment can be found in Userflow .

Used components

A brief description of modules and principles we use:

  • COmanage
    COmanage an Internet2 initiative started some years ago an which has also been tested within AARC. Of the available solutions for group management, invites and attribute management we think this is the most future proof. SURF has direct connections with the developers of COmanage. 
    SATOSA ("A configurable proxy for translating between different authentication protocols such as SAML2, OpenID Connect and OAuth2") is used in the current phase to technically connect services so authentication requests can be managed. SUNET has been instrumental in development of SATOSA.
  • PyFF
    For metadata handling and the WAYF. NORDUnet has been instrumental in development of PyFF.
  • CMService
    For showing and managing Consent
  • LDAP
    Together with COmanage and SATOSA, LDAP provides the technical basis for SCZ. In the LDAP database we store application specific passwords (ASP), public ssh/pgp keys, grid certificates etc, so non-web applications can retrieve them.
  • Non edu ('guest') usage
    SURF has extensive knowledge of supporting people without an edu account, for instance as it is needed for the SURFconext service (currently OneGini is used to provide a 'guest IdP' in SURFconext ). SURF-employees where involved in several AARC projects focuses on the question how to provide access for people without an edu-account.
  • Account Linking
    Most people have several online identities, each of which has it's own value. Some people have multiple institutional accounts, some have a national identity, a bankId etc. Within the SCZ context there is a need to link those accounts together, also to prevent someone loosing access to all resources, just because one account has been revoked.
  • Strong 2 step Authentication
    Many services projected to be connected to the SCZ infrastructure deal with sensitive or special personal data, which needs strong authentication for an extra layer of protection, sometimes required as either the client or service provider needs t adhere to standards like NEN 7510. The SCZ project can leverage the experience SURF has with providing SURF Strong Authentication.
  • Federated authentication and non-web resources (like SSH and webDAV)
    For web applications providing federated access, with protocols like SAML and OIDC, is pretty straight forward. But researchers often use tools from the command prompt, where SAML and OIDC don't provide a solution for. SCZ will provide a way to connect the federated way of working with access to these 'non-web' resources (the LDAP and PAM play an important role in this).
  • Containerization
    Within the SCZ project we will test whether using containers provides advantages in scalability, management, stability, availability etc.


  • No labels