Single Sign-on
Vor allem bei Cloud-Lösungen stellt sich die Frage: „Wie melden sich meine Anwender an der neuen Applikation an?“ – Idealerweise lautet die Antwort: „Am besten gar nicht, denn dies geschieht von selbst via Single Sign-On„.
Index
Einfache Anmeldung mit Single Sign-on
Sie können diese Herausforderung mit Hilfe der Kontenföderation elegant lösen. Das Ziel sollte sein: ein echtes „Single-Sign-On“ (SSO) für Ihre Anwender zu ermöglichen.
Sie haben verschiedene Möglichkeiten, SSO zu implementieren. Wir stellen Ihnen einige Varianten und deren Vorzüge vor.
Varianten der Einmalanmeldung
Übersetzt man Single Sign-on als „Einmalanmeldung„, bedeutet dies, dass der Anwender nur beim Start des Computers seinen Nutzernamen und Passwort eingibt. Danach hat er Zugriff auf alle Anwendungen.
Sie haben aber verschiedene Möglichkeiten, eine Einmalanmeldung für den Anwender zu implementieren:
1. Jede Anwendung hat das gleiche Login
Schnell eingerichtet, aber Ihre Benutzer benötigen verschiedene Kennwörter.
2. Synchronisieren Sie Konten und verwenden Sie überall die gleichen Daten
Praktisch erfolgt dabei aber in jeder Anwendung eine Anmeldung (Same Sign-on).
3. Föderieren Sie alle Konten / Login-Anfragen mit einem Identitätsspeicher
Dies bietet die meisten Vorteile und die Datenhoheit bleibt bei Ihnen (echtes Single Sign-on).
1. Individuelle Konten
Die einfachste Variante: Jeder Anwender bekommt ein individuelles Kennwort pro Applikation.
Dies ist auf den ersten Blick mit dem geringsten Aufwand verbunden. Genauer betrachtet, führt es aber schnell zu Frustration bei Ihren Benutzern und danach beim Helpdesk: „Wie war denn nochmal mein Kennwort in Anwendung XY…“. „Warum habe ich in Anwendung „Z“ noch kein Konto, obwohl ich schon 2 Wochen im Unternehmen bin?“
2. Kontensynchronisation „Same Sign-on“
Eine andere Variante ist ein sogenanntes „Same Sign-on“. Dabei richten Sie eine Synchronisation Ihrer Identitäten im lokalen Identitätsspeicher (in den meisten Fällen Active Directory) mit den Anwendungskonten ein. Technisch gibt es hierzu unterschiedliche Möglichkeiten. Oft bringt die Webanwendung auch schon eine Lösung mit.
Das Kennwort der Anwender kann dann auch in vielen Fällen mitsynchronisiert werden. Man spricht dann auch von „Same-Sign-on“, da Benutzername und Kennwort identisch sind.
Neue Benutzer werden automatisch, zum Beispiel einmal pro Nacht, angelegt. Kontenänderungen werden im gleichen Zug übernommen.
Aber auch diese Variante hat ihre Schwächen:
- Sie geben sensible Informationen (z.B. Kennworte verschlüsselt oder unverschlüsselt) ihrer Anwender an Fremdfirmen.
- Sie müssen Ihre Kennwortrichtlinie mit der des Service-Providers abgleichen.
- Auch wenn Sie häufig synchronisieren, eine Änderung kann trotzdem noch eine Stunde oder einen Tag brauchen. Lange genug, um einen Anwender durch unterschiedliche Kennworte zu verwirren.
- Im Falle einer Kontensperrung wegen Datenmissbrauchs kann eine Stunde lang genug sein, um vertrauliche Daten aus einer Fremdanwendung zu missbrauchen.
3. Kontenföderation „Single Sign-on“
Wenn alle Login-Anfragen gegen ein und denselben Identitätsspeicher gehen, handelt es sich um ein echtes „Single-Sign-On“. Dieser wird mit der Kontenföderation erreicht.
Vorteile des „echten“ Single Sign-ons::
- Alle sensiblen Kontendaten befinden sich ausschließlich unter ihrer Hoheit.
- Sie entscheiden, wie die Identitäten nach außen repräsentiert werden.
- Ihre Anmeldeinfrastruktur wird nach außen hin abstrahiert.
- Es werden nur Internet-geeignete (http/https) Protokolle verwendet.
- Eine Kontensperre im AD sperrt augenblicklich alle Logins in allen angebundenen Webanwendungen.
- Eine Kennwortänderung ist sofort wirksam und unterliegt auch nur den AD Richtlinien
Benutzeranmeldung über eine vertraute Stelle
Bei dieser SSO-Variante kommt der Ansatz der Kontenföderation zum Einsatz.
Die Web-Anwendung kümmert sich nicht mehr selbst um die Benutzeranmeldung, sondern überlässt dies einer zentralen Stelle, der sie vertraut.
Um die Anmeldungs-Token zwischen Aussteller und vertrauender Anwendung zu übertragen, wurde SAML (Security Assertion Markup Language) etabliert. Dieser Quasi-Standard wird heute von den meisten aktuellen Anbietern unterstützt.
Active Directory Federation Services (ADFS)
Wenn Sie bereits ein Active Directory (AD) betreiben, bietet Ihnen Microsoft hierzu ein kostenfreies Produkt an: Active Directory Federation Services (ADFS). Voraussetzung ist eine bestehende Windows Server Lizenz.
Installiert auf einem oder mehreren Servern Ihrer internen IT Infrastruktur, stellt ADFS die zentrale Anlaufstelle für die Autorisierung Ihrer Webanwendungen dar. Es ist hierbei gleichgültig, ob die Applikation intern oder extern gehostet wird.
Was passiert nun, wenn Sie auf eine solche Anwendung zugreifen?
Zugriff mit ADFS
Wenn Sie noch nicht an der Anwendung angemeldet sind, werden Sie automatisch an den ADFS-Dienst weitergeleitet. Sind Sie bereits an Ihrem Arbeitsplatz angemeldet, generiert ADFS direkt einen „Passierschein“, ein sogenanntes Token. Dies geht umgehend zurück an die aufrufende Web-Applikation. Möchten Sie z.B. als externer Anwender zugreifen, präsentiert ADFS Ihnen eine Login-Maske und verifiziert Ihre Login-Daten gegen Ihr Active Directory.
Das vom ADFS-Server ausgestellte Token kann nun alle notwendigen Informationen enthalten, die für die Arbeit mit der Web-Applikation benötigt werden. In jedem Fall wird eine eindeutige ID benötigt. Häufig ist dies ihre E-Mail-Adresse oder der Windows-Anmeldename. Weiterhin können aber auch Rolleninformationen enthalten sein, die Ihre Berechtigungen innerhalb der Anwendung steuern.
ADFS mit der Option Vertrauensstellung
Die enthaltenen Daten werden als „Ansprüche“ (Claims) bezeichnet. Man spricht daher auch vom „Claims-based-Access“.
Jede Anwendung wird getrennt innerhalb des ADFS konfiguriert. Man spricht dann von Vertrauensstellungen oder „Trusted Parties“.
Durch spezielle Zertifikate und Verschlüsselungsverfahren wird sichergestellt:
- dass die Cloud-Applikationen auch wirklich nur Ihrem internen Token-Provider vertraut
- kein anderer Service fälschlicherweise „Tickets“ ausstellt und
- somit Fremden Zugriff auf die Anwendung ermöglicht.
Wie eine solche ADFS-Architektur für Ihr Unternehmen aussieht, hängt von vielen Faktoren ab, die sorgfältig betrachtet werden müssen. Unsere Spezialisten unterstützen Sie gern bei der Analyse und Umsetzung der Anforderungen.
