Single Sign On (künftig mit SSO abgekürzt) ist ein klassisches Beispiel für ein Feature, bei dem man meinen würde, es ist eine Kleinigkeit. In der Realisierung ist es jedoch wesentlich komplexer und mehr Aufwand.
In dieser Blogartikel-Serie möchte ich das Thema SSO beleuchten. Einerseits werden wir uns die Theorie ansehen, und andererseits auch die Praxis. Ziel ist für diverse Services (semi-statische Seiten, Java Anwendungen, Node Anwendungen, …) SSO zu realisieren.
Dies soll sich natürlich auch in meine Docker-Landschaft integrieren. Das bedeutet die benötigten Services müssen selbst in Containern laufen.
Inhalt
Die Theorie
Was ist SSO eigentlich?
Single Sign-on (SSO, mitunter auch als „Einmalanmeldung“ übersetzt) bedeutet, dass ein Benutzer nach einer einmaligen Authentifizierung an einem Arbeitsplatz auf alle Rechner und Dienste, für die er lokal berechtigt (autorisiert) ist, vom selben Arbeitsplatz aus zugreifen kann, ohne sich an den einzelnen Diensten jedes Mal zusätzlich anmelden zu müssen. Wechselt der Benutzer den Arbeitsplatz, wird die Authentifizierung, wie auch die lokale Autorisierung, hinfällig.
Wikipedia Artikel Single Sign-On
Das bedeuted einerseits:
Beim SSO sind immer mindestens 2 Systeme involviert, im Normalfall sogar deutlich mehr.
und andererseits:
Die Systeme tauschen (im Normalfall) nicht nur aus, dass der User eingeloggt ist, sondern auch, welche Rollen / Berechtigungen dieser hat.
Aus welchen Teilen besteht SSO nun?
Identity-Provider (IDP): Das Service, gegen welches der User sich authentifiziert. Der User sieht hiervon maximal die Loginmaske – sofern diese nicht von einem Gateway bereit gestellt wird.
Service-Provider (SP): das Service, welches der User tatsächlich nutzen möchte. Beispiele wären eine Zeiterfassung, ein Ticketing-System oder ein CMS. Der SP wird teils auch als Relying Party oder Consumer betitelt.
Verfahren: Das Verfahren legt fest, wie die tatsächliche Durchführung der Anmeldung geschieht. Beispiele wären hier SAML, OIDC, CAS,…
Das bedeutet, um einen SP an den IDP anzuschliessen, müssen beide ein gemeinsames Verfahren unterstützen.
Die Qual der Wahl
Sehen wir uns als nächstes an, welche IDPs wir zur Auswahl haben:
| Name | Art | Docker | Verfahren | Lizenz / Nutzung | Ressourcenverbrauch |
|---|---|---|---|---|---|
| Keycloak | OnSite | Ja | OIDC, SAML | Frei | Hoch |
| OpenAM | OnSite | Ja | CDSSO, SAML 2.0, OAuth 2.0, OIDC | CDDL / Frei | Mittel |
| Gluu | OnSite | Ja | OAuth 2.0, OIDC, UMA, SAML 2.0 | ||
| FusionAuth | OnSite, Cloud | / Frei, Kommerziell | |||
| LemonLDAP | OnSite | Ja | SAML 2.0 / Shibboleth, OID 2.0, OIDC, CAS | GPL / Frei | |
| Apereo CAS | OnSite | Nein | CAS, SAML, OAuth, OID, OIDC | Apache 2.0 / Frei | |
| Aerobase | OnSite | OIDC, OAuth 2.0, SAML 2.0 | Frei | vmtl. Hoch, da Fork von Keycloak | |
| Shibboleth | OnSite | Shibboleth / SAML | Apache 2.0 / Frei | ||
| JumpCloud | Cloud | – | Kommerziell | Keiner | |
| Okta | Cloud | – | OIDC | Freemium (Frei für Entwickler für 5 OIDC Apps) | Keiner |
Ich werde nicht weiter auf die Cloud-Dienste eingehen, da diese für meinen Anwendungsfall uninteressant sind. Möglicherweise sehe ich mir diese in Zukunft noch an.
Fazit
Wir haben nun an der Oberfläche von SSO gekratzt und haben ein grobes Verständnis davon, wie ein solches aufgebaut ist. Der nächste Schritt ist, mit einem der existierenden IDP Lösungen und den eigenen Services als SPs zur Praxis zu schreiten.
Quellen
https://developers.redhat.com/blog/2018/10/08/configuring-nginx-keycloak-oauth-oidc
https://www.comakeit.com/blog/quick-guide-using-keycloak-identity-access-management/
https://www.alacrinet.com/iam-sso
https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
https://heipei.io/2015/09/23/nginx-sso-Simple-offline-SSO-for-nginx/
http://nginx.org/en/docs/http/ngx_http_auth_request_module.html
https://github.com/tarachandverma/nginx-openidc
https://developer.okta.com/blog/2018/08/28/nginx-auth-request
