On his AOE conference talk, Sebastian Rose sketches the idea of an Identity and Access Management platform using single sign-on for services provided to employees and customers.
https://www.aoe.com
3. Disclaimer
All characters and events depicted in this film are entirely fictitious. Any similarity to actual
events or persons, living or dead, is purely coincidental.
All uses of software products and configurations depicted
in this presentation are entirely fictitious. Any similarity to
actually used software products or existing configurations
at AOE, now or in the past, is purely coincidental.
6. Motivation - Summary
No Single Sign-On
Users/Personal data sets are distributed
Permissions are managed in a distributed way
LDAP User/password is given to different services
14. Solution - Summary
Single-Sign-On
Users/Personal data sets only in one place,
editable by the user
Permissions are only in one place
LDAP User/password is only handled by trusted
identity provider
16. Solution - Summary (add-on)
Existing software (products) problem:
If there is some kind of integration as a client:
roles and permissions are missing
No problem being Authentication
Provider; being Client is not a first
class feature
Willkommen zu meinem Vortrag über einen AOE Identity Provider.
Allgemein: Mails, Kalender, Raumbuchungen, Virt. Taskboard, Artefaktverwaltung, Codereview, Sourcecoudeverwaltung, Mittagessen, Urlaubsverwaltung, etc.
Projekt: Build-Server, Logging, Monitoring, Mockingservices
Fremdsoftware (open-source, kostenpflichtig, etc.) vs. Selbstgeschrieben
selbst betrieben vs. SAAS.
Großteil Authentifizierung Benutzername und Passwort.
Manche dieser Services nutzen das Firmen LDAP, so dass die gleichen Credentials für verschiedene Services verwendet werden können.
Passwort kommt mit Software in Berührung und es Bedarf dem Vertrauen in diese Software.
Verteilte Daten ggf. unterschiedliche Informationstrukturen/Credentials
kein Single Sign On
Verwaltung der Benutzer
Zugriffsrechte über Gruppen/Rollen/Permissions in den einzelnen Services
Features bez. Authentifizierung eher unterschiedlich und meist auf User/Password festgetackert
Zusammengefasst einige Dinge über die man nachdenken kann, ob sie nicht anders gehen
Ein neuer spezialisierter Service
Besonders geschützt
Vertrauenswürdig
Nur hier findet authentifzierung und authorisierung statt statt
Benutzer: AOE people
Starke und langfristig angelegte Grundlage
Idee aus Oauth: Authorization Server
Idee aus Open ID Connect: OpenId Provider
SAML: persönlich keine Erfahrung
Open ID Connect, OAuth2 oder SAML.
Standards sehr umfangreich und mit vielen Details
2014
Gremium/Standardisierung mit auch einer Zertifizierungsgrundlage
Liste von Software
Keycloak: github open-source, sehr aktiv community, regelmäßige releases, commercial supprt über redhat,
Immernoch mein Favorit
Andere sind gut unterwegs und ein Blick lohnt sich ggf.
Auszug an nötigen Schritten
klaren Verantwortlichen/Regelmäßigen Updates/Absicherungen/etc. Verfügbarkeit
Aufsetzen: Instanzen bis Produktion, Mailing, Logging, Timeouts, etc.
--- Keycloak nutzbar als Authentifizierungsservice
UI Customizing
Gruppen und Rollen festlegen
Permissions festlegen
Architekturaspekte:
- LDAP immer noch die Datenbasis
- Entsprechende Standards als Schnittstellen
- Authentifizierung, Benutzerverwaltung, Benutzerselbstverwaltung als eigenes HTML (hier noch nicht customized)
- Existierende Services als Client einrichten und den Services die Integration mit einem der Standards konfigurieren/beibringen
- Ein wichtiges System, Ausfall bedeutet ggf. viel Stillstand
Reine Client Perspektive – Backend/APIs aussen vor
Authentifizierung / Authorisierung erfolgt im Dialog zwischen Benutzer/Browser und dem OpenID Provider (und nur dort)
Services müssen umleiten (http- redirect)
Wenn z.B. aufgrund der Session zwischen Browser und OpenId Provider keine Interaktion mehr nötig ist: SSO
Services können mit zur Verfügung gestelltem Access-Token / ID-Token auf Benutzer-Daten zugreifen.
Neue und existiernde Services als OIDC-Client oder SAML Client anbinden
Selber schreiben, Bibliotheken, Adapter (Keycloak), Apache Modul, Keycloak Proxy
Neue eigene Software, neue systeme: Klar.
Existierende Software/ Software Produkte/Open Source
In der Theorie: Kein Problem, Ziele alle erreicht.
Keycloak kurz vorstellen
(Nicht eigene Software/Projekt/Domäne für den Kunden)
Integration von Software Produkten