Applikationen und deren Clients Verwalten
Einleitung
Um eine Applikation mit dem Identity Store der CoreOne Suite zu bedienen, muss diese mit allen Clients und dessen Flows vorgängig erfasst und entsprechend konfiguriert werden. Die Applikation kann beispielsweise ein ERP System sein. Dieses ERP System kann wiederum über ein Web-Interface und eine Desktop Anwendung verfügen. Beide müssen als Clients dieser Applikation erfasst werden. Greift der Backend Dienst des ERP Systems über das CoreOne Suite Application Interface (API) auf Daten zu, muss dieser auch als Client erfasst werden.
Applikation
Folgende Konfigurationsparameter sind vorhanden:
Parameter | Pflichtfeld | Beispiel-Werte | Beschreibung |
---|---|---|---|
Name | Pflicht | CoreOneSuite | Name der Applikation |
State | Pflicht | 1 | Status der Applikation |
Role Claim Type Name | c1s_role | Falls vorhanden, der Name der Role Claims, die speziell für diese Applikation erfasst wurden. | |
Is Trusted | Pflicht | false | Standardmässig muss der Benutzer seine Zustimmung erteilen, sobald der OIDC Scope Offline Access angefordert wird. Dieses Verhalten ist auch korrekt, da die Applikation auf die Benutzerdaten auch dann zugreifen kann, wenn der Benutzer nicht angemeldet ist. In gewissen Fällen ist diese Zustimmung aber nicht gewünscht und kann durch das Setzen dieses Feldes übersteuert werden. Ein Beispiel für einen solchen Fall ist die CoreOne Suite selber. Die Applikation ist so oder so im Besitz der Benutzerdaten und es macht daher keinen Sinn den Benutzer bei jeder Anmeldung um seine Zustimmung zu Fragen. |
Client
Folgende Konfigurationsparameter sind vorhanden:
Parameter | Pflichtfeld | Beispiel-Werte | Beschreibung |
---|---|---|---|
Name | Pflicht | CoreOne Suite | Eindeutiger Name des Clients. |
Identifier | Pflicht | CoreOneSuite | Eindeutiger Identifier des Clients. Wird beim Validieren der Access Tokens bzw. beim Lösen derer verwendet. |
Redirect Uri | Pflicht | regex:https://localhost(?:/.*)? | Wohin der Benutzer nach erfolgreichem Login weitergeleitet werden darf. Die Redirect Uri kann von der Applikation angegeben werden. Sie wird jedoch mit dem angegebenen Regex geprüft. |
Require Client Secret | Pflicht | true | Ob für den Verbindungsaufbau bzw. das Lösen des Tokens ein Client Secret verwendet werden soll. Ist abhängig vom konfiguriertem Flow. |
Identity Token Liftetime | Pflicht | 300 | Wie viele Minuten ein Identity Token gültig ist |
Access Token Liftetime | Pflicht | 300 | Wie viele Minuten ein Access Token gültig ist |
Authorization Code Lifetime | Pflicht | 300 | Wie viele Minuten ein Authorization Code gültig ist |
Absolut Refresh Token Lifetime | Pflicht | 300 | Wie viele Minuten ein Token alt sein darf, bevor er nicht mehr erneuert werden kann. Absolut heisst hier, wie viele Minuten ab Ausstellungszeitpunkt. |
Sliding Refresh Token Lifetime | Pflicht | 300 | Wie viele Minuten ein Token alt sein darf, bevor er nicht mehr erneuert werden kann. Sliding heisst hier, dass der Token mehrmals erneuert werden kann und der neue Token wieder für x Minuten gültig ist. |
Require PKCE | Pflicht | false | Ist bei gewissen Client erforderlich. |
Allow Plain Text PKCE | Pflicht | true | Ob der PKCE als Plain Text übermittelt werden darf oder nicht. |
Allow Access Token via Browser | Pflicht | true | Ob der Access Token via Browser geliefert werden darf. |
Allow Offline Access | Pflicht | true | Ob ein Refresh Token ausgestellt wird oder nicht. |
Always Include User Claims in ID Token | Pflicht | false | Ob der User Claim im ID Token enthalten sein soll oder nicht. |
Update Access Token Claims on Refresh | Pflicht | true | Ob die Access Tokens beim Refresh erneuert werden sollen oder nicht. |
Include JWT Id | Pflicht | false | Ob die Token ID im Token ausgeliefert werden soll oder nicht. |
Post Logout Redirect URIS | Pflicht | regex:https://localhost(?:/.*)? | Wohin der Benutzer nach erfolgreichem Logout weitergeleitet werden darf. Die Redirect Uri kann von der Applikation angegeben werden. Sie wird jedoch mit dem angegebenen Regex geprüft. |
Refresh Token Usage Type Id | Pflicht | 1 | Für ReUse den Wert 1 setzen, für OneTime den Wert 2 setzen. |
Refresh Token Expiration Type Id | Pflicht | 1 | Für Absolute den Wert 1 setzen, für Sliding den Wert 2 setzen. |
Access Token Type | Pflicht | 1 | Für JWT den Wert 1 setzen, für Reference den Wert 2 setzen. |
Logon Method Id | Pflicht | 1 | Die zu verwendende Logon Methode |
Flows
Pro Client können unterschiedliche Flows definiert werden. Hier ist eine Liste der zur Verfügung stehenden Flows:
Flow ID | Beschreibung | Verwendung |
---|---|---|
1 | Authorization Code | Viele PHP Frameworks unterstützen nur diesen Flow |
2 | Implicit | Standard Flow. Die meisten .NET Implementierungen verwenden diesen Flow. |
3 | Hybrid | - |
4 | Client Credentials | - |
5 | Password | - |
6 | Custom | - |
Logon Methoden
Folgende Standard Logon Methoden stehen zur Verfügung. Die Liste ist nicht abschliessend und dienen nur zur Illustration. Die Liste der vollständigen Logon Methoden entnehmen Sie Ihrer Installation.
Flow ID | Beschreibung |
---|---|
1 | Password |
2 | TOTP |
How-to Artikel
Verwandte Artikel
© ITSENSE AG. Alle Rechte vorbehalten. ITSENSE und CoreOne sind eingetragene Marken der ITSENSE AG.