Blog of Manuel Manhart

A techie blog

IT, Security

SSO (Single Sign On) realisieren – Teil 1

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

  1. Die Theorie
  2. Die Qual der Wahl
  3. Fazit
  4. Quellen

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:

NameArtDockerVerfahrenLizenz / NutzungRessourcenverbrauch
KeycloakOnSiteJaOIDC, SAMLFreiHoch
OpenAMOnSiteJaCDSSO, SAML 2.0, OAuth 2.0, OIDCCDDL / Frei
Mittel
GluuOnSiteJaOAuth 2.0, OIDC, UMA, SAML 2.0
FusionAuthOnSite, Cloud / Frei, Kommerziell
LemonLDAPOnSiteJaSAML 2.0 / Shibboleth,
OID 2.0,
OIDC, CAS
GPL / Frei
Apereo CASOnSiteNeinCAS, SAML, OAuth, OID, OIDCApache 2.0 / Frei
AerobaseOnSiteOIDC, OAuth 2.0, SAML 2.0Freivmtl. Hoch, da Fork von Keycloak
ShibbolethOnSiteShibboleth / SAMLApache 2.0 / Frei
JumpCloudCloudKommerziellKeiner
OktaCloudOIDCFreemium (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://gluu.org/docs/

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

https://github.com/vouch/vouch-proxy

https://developers.home-assistant.io/docs/en/auth_api.html

Comments are Closed