Single Sign On mit OpenID Connect

BuildArk https://www.flickr.com/photos/buildark/2165792976 (CC BY-SA 2.0)

BuildArk https://www.flickr.com/photos/buildark/2165792976 (CC BY-SA 2.0)

Wenn die Firma grösser wird, hat sie oft mehrere Websites. Eine für den Shop, eine für die Community, ein paar Marketing Websites und vielleicht noch einen Blog. Auf einigen Sites wird ein Login benötigt, auf anderen nicht.

Das Szenario lässt sich beliebig verkomplizieren. Im Prinzip geht es um eine einheitliche Benutzerverwaltung im Unternehmen.

Mit Facebook, Google und Twitter kam das Thema wieder auf, weil es plötzlich so einfach war, sich mit einem Facebook, Google oder Twitter Konto bei einer anderen Website einzuloggen. Die Firmen hatten einfach das OAuth Protokoll proprietär erweitert und boten diesen komfortablen Service.

Mit OAuth2und OpenID Connect gibt es seit 2 Jahren eine Authentifizierungmöglichkeit, aufbauend auf dem weit verbreiteten OAuth 2.0 Framework. Das Motto des Projektes ist:

Einfache Dinge sollten einfach und komplizierte Dinge sollten möglich sein.

OpenID selbst ist ein dezentrales Authentifizierungssystem für webbasierte Dienste. Es kümmert sich um die Verwaltung von Identitäten und die Authentifizierung von Benutzern. Da beide Begriffe oft missverstanden werden:

  • Identität = „Sag mir etwas über dich!
  • Authentifizierung = „Beweise mir, dass du es bist!“

Das System kann für verteilte Anmeldeprozesse benutzt werden.

Bestandteile des Systems

Wenn OpenID Connect genutzt wird, gibt es mindesten einen Server, viele Clients, viele Benutzer und unterschiedliche Workflows.

OpenID OAuth 2.0 Provider (Server)

Auf diesem System wird der Identitäts- und Authentifizierungsdienst bereitgestellt.
Hier werden die Identitäten und optional zusätzliche Felder, wie die postalische Adresse, vom Benutzer selbst verwaltet.

OpenID Connect (Client)

Der Client kann eine Website oder eine App sein, die mit dem OpenID Server „fest verdrahtet“ ist.

Benutzer

Der Benutzer muss sich einmal beim OpenID Server registrieren. Danach kann er sich bei einem der OpenID Clients und dem OpenID Provider mit seinem Benutzernamen und Passwort anmelden.

Workflow

Der Benutzer besucht eine Client Website und klickt auf den Anmeldebutton. Der Client leitet weiter zum OpenID Server. Nach erfolgreicher Anmeldung dort leitet der OpenID Server ihn wieder an die anfragende Website zurück.
Per Definition vertrauen die OpenID Clients dem OpenID Server und fragen ihn nach Identität und Authentifizierung. Der OpenID Server antwortet und liefert seine Daten zurück. Falls der Benutzer auf der Client Website noch nicht existiert, wird er erstellt und angemeldet.

Hinweis:

  • Der beschriebene Anmeldevorgang hat nichts mit Benutzerberechtigungen und -rollen zu tun! Das wird im jeweiligen Client selbst geregelt und heißt Autorisierung.
  • Der Anmeldevorgang mit OpenID Connect ist kein Single Sign On sondern eine verteilte Authentifizierung. Es ist vergleichbar mit LDAP oder ActiveDirectory. 

SSL Verschlüsselung

Die Kommunikation zwischen den Clients und dem Server muss SSL/TLS verschlüsselt sein (Zertifikate).

Single Sign On (SSO)

Beim Single Sign On (einmaliges Anmelden) meldet sich der Benutzer einmal an und ist dann automatisch bei allen verbundenen Clients eingeloggt. Bei einem Wechsel des Clients (der Website) ist kein zusätzlicher Anmeldevorgang notwendig.

OpenID Connect allein ist kein Single Sign On, kann aber mit entsprechenden Erweiterungen dazu gemacht werden!

Verteilte Authentifizierung mit Drupal

Das CMS Drupal kann beide Rollen einnehmen. Es kann ein OpenID Connect Provider und/oder ein OpenID Connect Client sein. Beim OpenID Provider können außer Benutzername, E-Mail und Passwort auch weitere personenbezogene Daten, beispielsweise die postalische Adresse, gespeichert werden. Wenn der Benutzer zu einem anderen Client (Website) wechselt, muss er sich dort erneut anmelden, hat aber die gleichen Zugangsdaten (Name, Passwort) bei allen Clients.

Verteilte Authentifizierung am Beispiel Drupal
Verteilte Authentifizierung am Beispiel Drupal

Implementierung in Drupal und anderen CMS

In Drupal werden die folgenden Module und Bibliotheken benötigt:

Für den Server

Für den Client

  • openid_connect
    • erzeugt einen neuen Login Block, der auf die Zusammenhänge hinweist “melde dich an mit …”.
    • verarbeitet die Daten des OpenID Providers
    • jeder OpenID Provider kann genutzt werden
    • Es gibt keine „Benutzer bearbeiten“ Seite mehr (Die ist auf der OpenID Server Seite und betrifft die Felder, die auf dem Server gespeichert sind)
  • openid_connect_sso
    • konfiguriert das OpenID Connect für Single Sign On.
    • übernimmt den Redirect sowie den An- und Abmeldevorgang

Auch eine WordPress Site könnte den Drupal OpenID Server nutzen. Dazu wird beispielsweise das Plugin Generic OpenID Connect benötigt.

Wenn alles installiert und konfiguriert ist, läuft die Anmeldung folgendermaßen ab. Hier ein Beispiel in Drupal 7:

Anmeldung mit OpenID Connect
Anmeldung mit OpenID Connect

Links


tl;dr: Single Sign On mit OpenID Connect schafft Übersicht bei den Benutzer

Autor: Hagen Graf

consultant, author, trainer, solution finder, web architect, developer, open source lover, visionary, orator, the good old webmaster. Able to simplify!

Kommentar verfassen