Versions Compared

Old Version 2

changes.mady.by.user Carlo Meier (Unlicensed)

Saved on

compared with

New Version Current

changes.mady.by.user Severin Hasler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

Table of Contents

Ü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.

...

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

Die Implementation folgt der folgenden OpenID Connect Spezifikationen: Final: OpenID Connect Core 1.0 incorporating errata set 1.

Glossar

Abkürzung

Begriff

Erklärung

OIDC

...

OpenID Connect

Das Protokoll das verwendet wird um den Authentifizierungsprozess durchzuführen

IdP

...

Identity Provider

...

In diesem

...

Anwendung - TODO RP - Relying party

Token - TODO

Abläufe/Authentifizierungsabläufe - TODO

Scope - Ein set an eigenschaften das optional ist/angefordert werden kann

Unterstützte Authentifizierungsabläufe

Endpunkte

Kurze übersicht über alle OIDC Endpunkte.

...

Fall der ECUI Server

RP

Relying Party

Die Client-Anwenung resp. deren Server

Scope

Ein Satz an Eigenschaften der angefordert werden kann

SPA

Single Page Applikation

Art von Web-Applikation

Weitere OpenID relevante Abkürzungen finden sich hier.

Unterstützte Authentifizierungsabläufe

Die vorliegende Implementation unterstützt die folgenden Authentifizierungsabläufe:

Endpunkte

Die folgenden Endpunkte stehen zur Verfügung:

URL

Zweck

/.well-known/openid-configuration

...

Konfiguration

Beispiel, siehe Quino10 Sandbox openid-configuration

...

...

/api/v1/connect/token

...

Token

/api/v1/connect/authorize

Authorization

...

/api/v1/connect/logout

Logout

...

/api/v1/connect/userinfo

...

User info

/.well-known/jwks

...

Menu im ECUI

  • Anwendungen - menupunkt kurz beschreiben

  • Authorisierungen - menupunkt kurz beschreiben

  • Tokens - menupunkt kurz beschreiben

...

JWT Konfiguration

Unterstütze Scopes

Scope

Zweck

openid

Benötigt: Liefert das Subject bei der User info

email

Liefert die email bei der User info

phone

Liefert die telefonnummer bei der User info

roles

Liefert die rollen bei User info

profile

Liefert infos wie name, benutzername bei der User info

Anwendung

Damit sich eine externe Anwendung über den Quino IdP ECUI Server anmelden kann. Muss ein Datensatz für , muss diese Anwendung vorhanden entpsprechend konfiguriert sein. Die local Anwendung ist der Anwendung local entspricht dabei dem vorkonfigurierten Datensatz für das login Login über das die eigentliche ECUI Applikation.

Note

Es

...

wird stark empfohlen mit

...

dieser Konfiguration nicht zu experimentieren.

...

Konfiguration

Die folgende Menüstruktur steht für die Konfiguration von Applikationen welche OpenID benutzen möchten zur Verfügung:

  • Anwendungen - Eine Liste aller registrierten Anwendungen

  • Autorisierungen - Liste aller registriertenAutorisierungen

  • Tokens - Liste der herausgegebenen Tokens

...

Client Id

Jeder client Jede Anwendung benötigt eine client id, diese wird verwendet um den client die Anwendung eindeutig zu identifizieren. Für Details wird auf die Spezifikation verwiesen.

Anzeigenamen

Dieser Name wird dem Benutzer angezeigt wenn er sich Anmeldet.

Anwendungstypen

type confidental -> benötigt client secret

type public -> kein client secret (wird nicht beachtet)

Berechtigungen

anmeldet respektive die entsprechende Einwilligung abgefragt wird.

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 wird 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.

Note

Es muss ein zufällig generierter Wert verwendet werden.

Für Details wird 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

Jaept:device

Erlaubt zugriff auf den Geräte-Endpunkt

Nein

ept:introspection

Nein

ept:logout

Erlaubt zugriff auf den Logout-Endpunkt

Ja

ept:revocation

Nein

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

Jagt:urn:ietf:params:oauth:grant-type:device_code

Erlaubt das verwenden des Gerätetyp Grant

Nein

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

...

redirecturi -> uri auf die weitergeleitet wird bei erfolgreicher anmeldung

PostLogoutRedirectUris -> uri auf die weitergeleitet wird bei abmeldung

Tokens

TODO

...

Authorisierungen

Hier sind alle mit dieser Anwendung

...

URLs

Ein 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

Listet alle mit dieser Anwendung assoziierten Tokens. Pro Anmeldung wird ein neues Token generiert.

...

Autorisierungen

Listet alle für diese Anwendung gegebenen Autorisierungen. Dies beinhalten auch eine allenfalls erteilte Zustimmung für eine Applikation, um auf die Daten des Benutzer im definierten Umfang zuzugreifen .

...

Weiterführende Links