Single-Sign-On-Systeme - JAXenter

Single-Sign-On-Systeme

Single Log Out

Ein weiteres interessantes Merkmal einiger SSO-Systeme ist die Fähigkeit, analog zum einmaligen zentralen „Sign-On“, einen zentralen „Log-Out“ durchzuführen. Denn ist ein Benutzer bei vielen verschiedenen Anwendungen angemeldet, wäre es umständlich sich bei jeder dieser Anwendungen gesondert abmelden zu müssen. Bietet ein SSO-System „Single Log Out“ (SLO) Funktionalität, so muss die Übersicht behalten werden, welcher Benutzer bei welcher Anwendung authentifiziert ist, um bei einem SLO den Benutzer automatisch von allen Anwendungen abzumelden. Interessanterweise spielt das Format des Tokens eine große Rolle für die SLO-Funktionalität. Zum Beispiel existiert der SAML-Standard in zwei Varianten (SAML 1 und SAML 2), die sich dadurch unterscheiden, dass SAML 2 Unterstützung für SLO mitbringt. Natürlich ist es nicht notwendig SAML zu verwenden um SLO zu implementieren, aber SAML bietet mehr oder weniger einen Standardweg hierfür.

Autorisierung in SSO

Um die Vor- und Nachteile der verschiedenen SSO-Systeme zu verstehen, muss man klar zwischen Authentifizierung und Autorisierung unterscheiden. Prinzipiell bietet ein SSO-System erst einmal nur einen zentralen Authentifizierungsmechanismus. Das heißt, wenn ein Benutzer sich dem SSO-System gegenüber als „Hugo“ authentifiziert hat, ist er automatisch auch bei allen, mit dem SSO-System verbundenen Systemen, als „Hugo“ authentifiziert. Bei der Mehrzahl aller Anwendungen ist die Authentifizierung eine Vorraussetzung für die Autorisierung. Meistens werden Autorisierungsentscheidungen anhand der Zugehörigkeit zu Rollen wie z. B. „administrator“, „user“ oder „power user“ getroffen. Das nennt man Role Based Access Control (RBAC).

In Java-EE-Webanwendungen gibt es zwei Möglichkeiten Rollen hinzuzufügen. Einerseits mittels Deklaration in der web.xml (Listing 1)

Listing 1
/business/*adminuser/setup/*admin

und andererseits programmatisch im Quellcode (Listing 2).

Listing 2
if(request.isUserInRole("user") || request.isUserInRole("admin")){
...
}

if(request.isUserInRole("admin)){
...
}

Die erste Variante erlaubt es, in Webapplikationen deklarativ zu definieren, welche Rollen Zugriff auf bestimmte URLs haben. In Listing 1 haben Benutzer in der Rolle „admin“ Zugriff auf die URLs /setup/* und /business/*, wohingegen Benutzer in der Rolle „user“ lediglich Zugriff auf /business/* haben. Die zweite Variante kontrolliert den Zugriff programmatisch aus der laufenden Anwendung heraus. In Listing 2 gibt z. B. eine Java Server Page (JSP) unterschiedliche Seiteninhalte zurück, je nach Rollenzugehörigkeit des Benutzers. Diese Art von RBAC verwendet man beispielsweise, um unterschiedliche Menüstrukturen für verschiedene Rollen zu erzeugen. Somit ist sie wichtiger Bestandteil sowohl in der Zugriffskontrolle als auch bei der Erzeugung von benutzerfreundlichen Anwendungen.

Alle SSO-Systeme bieten einen zentralen Mechanismus zur Authentifizierung, der wegen des einfachen Token-Verfahrens plattformunabhängig ist. Somit kann das SSO-System für die Authentifizierung in Java-EE-, .NET-, PHP- und anderen Plattformen eingesetzt werden. Um diese Plattformunabhängigkeit zu erhalten, kann die Autorisierung, wie sie oben für Java-EE-Anwendungen beschreiben wurde, nicht benutzt werden. Wenn das SSO System Webapplikationen unterstützen soll, die auf unterschiedlichen Plattformen laufen, dann darf es nicht auf Java-EE-Mechanismen zurückgreifen. Stattdessen muss ein allgemeiner Mechanismus zur Behandlung von Rollen angeboten werden, mit der die Autorisierung auch für Webapplikationen in .NET, PHP usw. funktioniert. Viele SSO-Systeme bieten daher „Clients“ für verschiedene Plattformen an, um die Webanwendungen anzubinden. Es ist die Aufgabe des „Clients“, eine Verbindung zwischen der Webanwendung und dem SSO-System zu schaffen, um die Autorisierung zu ermöglichen.

Cross Domain Single Sign-On

Wenn die Anwendungen in verschieden Domänen liegen, spricht man von „Cross Domain Single Sign-On“ (CDSSO). CDSSO wird benötigt, wenn z.B. zwei Partnerorganisationen kooperieren. In diesem Fall werden die Mechanismen zur Herstellung des Vertrauensverhältnisses zwischen den einzelnen Systemen meist wesentlich komplexer. Das hängt unter anderem von der Sessionverwaltung der Anwendungen ab. Verwendet eine Anwendung z. B. Cookies für die Sessionverwaltung, dann ist es nicht ohne Weiteres möglich, Informationen in der Session über verschiedene Domänen zu verwenden, da das Sicherheitsmodell des Browsers keine Zugriffe aus anderen Domänen auf die Cookies zulässt. Aus diesem Grund muss es beim CDSSO für jede Domain einen Authentifizierungsmechanismus geben. Diese dezentralen Komponenten tauschen untereinander Informationen über die Autorisierung des Benutzers aus.

Auswahl eines SSO-Systems

Bei der Auswahl eines SSO-Systems müssen einige relevante Merkmale betrachtet werden.

  • Wie einfach ist es, eine neue Anwendung in das System zu integrieren?
  • Welche Plattformen werden unterstützt? Werden nur Java-EE-Webapplikationen an das SSO-System angebunden oder werden auch .NET, PHP oder andere Plattformen benötigt?
  • Beinhaltet das System einen fertigen PEP, der die Rolleninformationen in die Anwendung transportieren kann?
  • Wie wird die Sessionbehandlung durchgeführt (Cookies, Hidden Fields, URL Rewriting)?
  • Werden alle Anwendungen unter derselben Domain (z.B. optimabit.com) laufen oder wird SSO über verschiedene Domänen benötigt?
  • Welche Arten von Datenbanken benutzt sollen werden, um die Authentifizierungsinformationen abzufragen (LDAP, JAAS, JDBC)? Und kann das SSO-System um eine eigene Anbindungen erweitert werden?
  • Welche Arten von Authentifizierungen sollen eingesetzt werden (Benutzername und Passwort, Zertifikate oder Biometrie)? Eventuell sollen diese Techniken kombinierbar sein.
  • Sollen neben „HTML-Webanwendungen“ auch Web Services unterstützt werden (SOAP oder REST)?
  • Ist „Single Log Out“ (SLO) erforderlich?
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.