Einleitung
Das unten aufgeführte Flow Chart zeigt exemplarisch den Authentication Prozess des CoreOne Authentication Services auf. Er zeigt insbesondere die folgenden Teilprozesse auf:
...
Teilprozess
...
Beschreibung
...
...
Der Level of Authentication kurz LoA beschreibt die Qualität der Authentifizierung. Dieser kann pro Applikation definiert werden und zwingt den Benutzer gewisse Login Schritte, wie Multi Faktor Authentifizierung, durchzuführen.
...
Externes Login / Föderierung
...
Durch externe Login oder auch Föderierung kann sich der Benutzer durch die Verwendung eines anderen IdP an der Applikation anwenden. Dies kann beispielsweise eine Anmeldung durch Google oder SwissID sein.
...
Registrierung durch Externes Login
...
Beschreibt den Prozess was bei einer Anmeldung mittels externem Login geschieht, sollte der Benutzer noch nicht im lokalen Meta Directory bekannt sein.
...
Registration Elevation
...
Sind für den Zugriff auf eine Applikation zusätzliche Informationen vom Benutzer gefordert, welche noch nicht im lokalen Meta Directory vorhanden sind, werden diese abgerufen.
...
Email Verifikation
...
Eine einmalige oder periodische Verifikation der angegebenen Email Adresse.
...
Datenschutzbestimmungen und Nutzungsbestimmungen
...
Der Benutzer muss den Datenschutz- und Nutzungsbestimmungen zustimmen. Diese Bestimmungen können versioniert sein.
...
Consent / Einwilligungen
...
Der Benutzer muss, je nach Konfiguration, seine Zustimmung erteilen, welche Informationen an die Applikation übertragen werden.
Authentication Prozess
Die nachfolgende Grafik zeigt den Standard Prozess ab. An gewissen Stellen ist er auf Grund der Lesbarkeit abgekürzt.
...
Introduction
Upon each authentication request, the CoreOne Suite executes various authentication steps. Those steps are depended on the configuration, the user data and the user behavior. The subsequent list gives you an overview of the possible steps. The steps are also executed in the order as shown below.
Subprocess | Description |
---|---|
Validate client | Validates if the requesting client is authorized to do so. |
Block request | Checks if the current IP has to many invalid logon attempts. |
Resolve user | Checks if the user has already been resolve. This is the case if there is a |
Check application access | Validates if the resolved user is allowed to access the requested application. |
Show login page | Presents the user with the appropriate authentication page. Note that this process contains a lot of sub-steps by itself, such as account merging with federated identities or password policy checks. |
User data missing / Attribute elevation | If additional information is required from the user to access an application, which is not yet available in the local meta directory, this information is retrieved. |
Check browser fingerprint | Generates a unique fingerprint of the browser. |
Check verification status | Checks if the user has pending verification steps, such as email verification. |
Terms and conditions | Checks if the user needs to accept the terms and conditions for the requested application. |
Unfinished certifications | Checks if the user has open certification processes. |
User up to date | Validates if the user needs to update any data such as passwords or email addresses. |
Inactive delegations | Checks if the user has inactive delegations for the requested application. |
Consent | Checks if the user has to give consent for the current application. |