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

OpenID Connect Spezifikationen: Final: OpenID Connect Core 1.0 incorporating errata set 1

Übersicht

Der ECUI Server kann neben der eigentlichen Web-Applikation auf Wunsch auch einen Single Sign-On (SSO) Server (IdP) auf der Basis des OpenID Connect Protokolls zur Verfügung stellen. So kann rund um die Portal-Lösung eine Single Sign-On Infrastruktur implementiert werden. In einem solchen Szenario verwendet das Portal natürlich selber auch die SSO Infrastruktur.

Für jedes in die SSO Infrastruktur integrierte Produkt können

  • 1:1 die schon für das Portal verwendeten User mit ihren Berechtigungen

oder

  • Login-Berechtigungen unabhängig von den Portal-Usern

verwendet werden. In beiden Fällen werden alle User in einer zentralen Datenbank verwaltet, sie bekommen aber je nach Zugangsberechtigung für die einzelnen Produkte angepasste Berechtigungen. Diese Berechtigungen können entweder manuell administriert oder aus vorhandenen Kundendaten automatisch abgeleitet/generiert werden.

Glossar

Abkürzung

Begriff

Erklärung

OIDC

OpenID Connect

Das Protokoll das verwendet wird um den Authentifizierungsprozess durchzuführen

IdP

Identity Provider

In diesem Fall, Quino

RP

Anwendung, Relying party

Scope

Ein Set an Eigenschaften das angefordert werden kann

OpenID relevante Abkürzungen finden sich hier.

Unterstützte Authentifizierungsabläufe

Endpunkte

Die folgenden Endpunkte stehen zur Verfügung:

  • Konfiguration - /.well-known/openid-configuration - Beispiel, siehe Quino10 Sandbox openid-configuration.

  • Token - /api/v1/connect/token

  • Authorization - /api/v1/connect/authorize

  • Logout - /api/v1/connect/logout

  • User info - /api/v1/connect/userinfo

  • JWT Konfiguration - /.well-known/jwks

Integration im ECUI

Die folgende Menüstruktur steht neu zur Verfügung auf Applikationen welche für Open ID konfiguriert wurden:

  • Anwendungen - Eine Liste von allen registrierten Anwendungen

  • Autorisierungen - Liste von allen registrierten Autorisierung

  • Tokens - Liste der herausgegebenen Tokens

Anwendung

Damit sich eine externe Anwendung über den Quino IdP anmelden kann. Muss ein Datensatz für diese Anwendung vorhanden sein. Die local Anwendung ist der Datensatz für das login über das ECUI. Es ist empfohlen mit dieser nicht zu experimentieren.

Client Id

Jede Anwendung benötigt eine client id, diese wird verwendet um die Anwendung eindeutig zu identifizieren.

Für Details sei auf die Spezifikation verwiesen.

Anzeigenamen

Dieser Name wird dem Benutzer angezeigt wenn er sich anmeldet respektive die entsprechende Einwilligung gibt.

Anwendungstyp

Dieses Feld kann zwei Werte haben:

  • confidental

    • Die Anwendung hat ein client secret, das heisst das client secret muss gesetzt werden und auch von der externen Anwendung mitgeschickt werden.

  • public

    • Die Anwendung verwendet kein client secret da es nicht möglich ist dieses sinnvoll einzusetzen. Beispielsweise bei Applikationen welche als SPA konzipiert sind.

Für Details sei auf die Spezifikation verwiesen.

Client Secret

Dieses Feld muss nur gesetzt werden wenn der Anwendungstyp ‘confidental’ ist. Dieses muss auch von externen Anwendungen mitgeschickt werden wenn diese den login Prozess starten möchten. Es ist zu empfehlen einen zufällig generierten Wert zu nehmen.

Für Details sei auf die Spezifikation verwiesen.

Berechtigungen

Ein JSON array von gegebenen Berechtigungen. Wird eine neue Anwendung erstellt, werden per default alle aufgeführt.

Präfixe

  • ept - Endpunkte Berechtigungen

  • gt - Grant Berechtigungen

  • rst - Antworttyp Berechtigungen

  • scp - Scope Berechtigungen

Liste

Wert

Beschreibung

Empfohlen

ept:authorization

Erlaubt zugriff auf den Authorization-Endpunkt

Ja

ept:logout

Erlaubt zugriff auf den Logout-Endpunkt

Ja

ept:token

Erlaubt zugriff auf den Token-Endpunkt

Ja

gt:authorization_code

Erlaubt das verwenden des ‘Authorization Code’ Grant

Ja

gt:client_credentials

Erlaubt das verwenden des ‘Client Credentials’ Grant

Ja

gt:implicit

Erlaubt das verwenden des Impliziten Grant

Nein

gt:password

Erlaubt das verwenden des Passwort Grant

Nein

gt:refresh_token

Erlaubt das verwenden des Token erneuerungs Grant

Ja

rst:code

Erlaubt das verwenden des Antwort-Typ ‘code’

Ja

rst:code id_token

Erlaubt das verwenden der kombination von ‘code’ und ‘id_token’ Antworttypen

-

rst:code id_token token

Erlaubt das verwenden der kombination von ‘code’, ‘id_token’, und ‘token’ Antworttypen

-

rst:code token

Erlaubt das verwenden der kombination von ‘code’ und ‘token’ Antworttypen

-

rst:id_token

Erlaubt das verwenden des Antwort-Typ ‘id_token’

Ja

rst:id_token token

Erlaubt das verwenden der kombination von ‘id_token’ und ‘token’ Antworttypen

Ja

rst:none

Erlaubt das verwenden des Antwort-Typ ‘none’

-

rst:token

Erlaubt das verwenden des Antwort-Typ 'token'

Ja

scp:address

Erlaubt das verwenden des scopes Adresse

-

scp:email

Erlaubt das verwenden des scopes Email

Ja

scp:phone

Erlaubt das verwenden des scopes Telefon

-

scp:profile

Erlaubt das verwenden des scopes Profil

Ja

scp:roles

Erlaubt das verwenden des scopes Rollen

-

Weiterleitungs urls

JSON array von gültigen Urls, auf welche diese Anwendung weiterleiten darf wenn das login erfolgreich war.

Die Url muss gemäss Spezifikation erfasst werden.

Postlogout Weiterleitungs urls

JSON array von gültigen Urls, auf welche diese Anwendung weiterleiten darf nach dem logout.

Tokens

Hier sind alle mit dieser Anwendung assoziierten Tokens. Pro Anmeldung wird ein Token generiert.

Autorisierungen

Hier sind alle für diese Anwendung gegebenen Autorisationen. Dies beinhalten auch einen allenfalls erteilte Zustimmung für eine Applikation um auf die Daten des Benutzer zuzugreifen im definierten Umfang.

Weitere links

  • No labels