DE10361840A1

DE10361840A1 - Verfahren zum Single sign-On an webbasierten Anwendungen über ein gemeinsames Auswahlmenü

Info

Publication number: DE10361840A1
Application number: DE2003161840
Authority: DE
Inventors: Ekkehard Gümbel
Original assignee: Net & Works Netzwerke und Serv; NET&WORKS NETZWERKE und SERVICE GmbH
Current assignee: Net & Works Netzwerke und Serv; NET&WORKS NETZWERKE und SERVICE GmbH
Priority date: 2003-12-30
Filing date: 2003-12-30
Publication date: 2005-08-04

Abstract

Technische Aufgabe und Zielsetzung DOLLAR A Single Sign-On bezeichnet den Zugriff auf verschiedene geschützte (also nicht-öffentliche) Ressourcen mit einmaliger Anmeldung, etwa mit Benutzername und Kennwort. Heutige Verfahren im webbasierten Bereich bringen erhebliche Nachteile mit sich, insbesondere fehlende Flexibilität und hoher Aufwand. Das neue Verfahren soll dies durch einfache Implementierbarkeit, auch in heterogenen Umgebungen, überwinden. DOLLAR A Lösung der technischen Aufgabe DOLLAR A Als Voraussetzung für den Zugang auf eine geschützte Web-Ressource muß der Anwender sich zunächst an einem zentralen System, z. B. einem Portal, anmelden. Beim Zugriff auf eine der geschützten Web-Ressourcen über das Portal werden verschiedene Informationen, u. a. der Benutzername, zusammengestellt und signiert und sodann z. B. als URL-Parameter übertragen. Die geschützte Web-Ressource prüft u. a. die Signatur und gewährt aufgrund dieser den Zugang. Ein Kennwort o. ä. wird nicht übertragen. DOLLAR A Anwendungsgebiet DOLLAR A Alle webbasierten Anwendungen mit zentraler Anmeldung und Verlinkung.

Description

Web-Portale, also die Integration verschiedener Web-Anwendungen in eine einheitliche Oberfläche oder zumindest in eine gemeinsame Hauptseite mit Auswahlmenü, sind heute sowohl im Internet als auch in anderen Netzen weit verbreitet.

Dabei stellt sich in zunehmendem Maße die Problematik, daß nicht nur "öffentliche" Bereiche zu integrieren sind, sondern auch solche, die eine Benutzeranmeldung erfordern ("geschützte Ressourcen"). Trifft dies auf mehr als eine der zu integrierenden Anwendungen zu, so ist anzustreben, daß sich ein Benutzer nicht an jeder geschützten Ressource erneut, sondern nur einmal (zentral) anmelden muß und dann auf alle geschützten Ressourcen zugreifen kann, für die er berechtigt ist. Dies wird als Single Sign-On bezeichnet.

Die Gewährleistung der Sicherheit ist dabei typischerweise oberste Randbedingung.

Die Idee des Single Sign-On ist nicht neu und soll daher auch hier nicht weiter begründet werden [vgl. jedoch z.B. US 2002/0144119]

Die Zahl der bislang zur Verfügung stehenden Single Sign-On Verfahren ist begrenzt und jeweils mit Eigenschaften bzw. Voraussetzungen behaftet, die ihren Einsatz auf spezielle Szenarien beschränken bzw. aufwendige Umstellungen einer eventuell bestehenden Systemlandschaft erfordern.

Ein Beispiel ist die Verwendung einer gemeinsamen Plattform mit integriertem Benutzermanagement (z.B. Java Application Server bzw. -Cluster) für Portal und alle geschützten Ressourcen, was eine erhebliche Einschränkung sowohl in Hinsicht auf die Softwareauswahl als auch auf die räumliche Verteilbarkeit bedeutet. [Bsp: http://www.bea.com/weblogic, http://www.ibm.com/websphere]

Ein weiterer Ansatz ist die verschlüsselte Übermittlung von Zugangsdaten (z.B. Benutzername und Kennwort) zu den einzelnen geschützten Ressourcen, dortige Entschlüsselung und Prüfung gegen die Benutzerverwaltung der Anwendung. Dieses Verfahren erfordert eine gemeinsame oder zumindest hinsichtlich der Zugangsdaten synchronisierte Benutzerverwaltung aller geschützten Ressourcen. Zudem bringt die Verwendung eines symmetrischen Schlüsselverfahrens für Kennwörter u.ä. systembedingt Sicherheitsnachteile. [Bsp: WO 02/39237]

Merkmal einiger Ansätze ist die Notwendigkeit, alle Zugriffe auf die geschützten Ressourcen über ein gemeinsames Gateway ("Reverse Proxy") zu führen, was zu komplizierteren und (insbesondere bei verschlüsselten Verbindungen) weniger performanten Kommunikationsbeziehungen führt. [Bsp: WO 01/72009]

Andere Verfahren erfordern zusätzliche Software auf Benutzerseite, sind also z.B. für Standard-Web-Browser nicht geeignet (und erfordern ggf. auch zusätzliche Sicherheitsinfrastruktur, z.B. Kerberos-Implementierungen, auf Serverseite.) [Bsp: US 2002/0144119]

Hinsichtlich der Übermittlung von Single Sign-On – Informationen wird im Web-Bereich heute vielfach mit Cookies gearbeitet, was potentiell sowohl Funktionsprobleme (Benutzer muß in den Browsereinstellungen Cookies erlauben) und Sicherheitsprobleme (zumindest bei persistenten Cookies) als auch Implementierungsschwierigkeiten (sofern die geschützte Ressource in verschiedenen Namensräumen, DNS-Domains, liegen) bringt.

Es wäre daher wünschenswert, über ein gleichzeitig einfaches, universelles, flexibles und sicheres Verfahren zu verfügen, welches die Schwachpunkte der bisherigen Verfahren überwindet.

Lösungsansatz

Für den Zugriff auf eine geschützte Ressource wird dem Benutzer auf einem zentralen System ("Portal"), an dem er angemeldet ist, eine Verknüpfung ("Link") angeboten. Wenn der Benutzer diesen Link anklickt, wird (u.a.) seine per Signaturverfahren durch das zentrale System bestätigte Identität an die geschützte Ressource übermittelt.

Die Übermittlung kann als Parameter in der URI geschehen.

Die geschützte Ressource verifiziert anhand dieser Signatur (und weiterer Sicherheitsmerkmale) die Gültigkeit der Anfrage. Ein Kennwort o.ä. des Benutzers wird nicht übermittelt bzw. verwendet. Sodann wird der Zugang zur geschützten Ressource mittels der von dieser vorgesehenen Mechanismen gewährt.

Optional können zusätzliche Sicherungsverfahren implementiert werden.

Problemlösung

Die Erfindung beschreibt ein Verfahren zum webbasierten Zugriff auf verschiedene geschützte Ressourcen durch Anmeldung an einem zentralen Web-Portal mit Single Sign-On.

1 beschreibt den Kernvorgang:
Der Benutzer greift mit seinem Browser [100] auf das Portal [200] zu und meldet sich dort per Authentisierungsdienst [210]an.

Der Portaldienst [220] sorgt nun typischerweise dafür, daß auf Basis der Benutzeridentität bzw. der zugeordneten Rollen die zulässigen Anwendungen einschließlich geschützter Ressourcen angeboten werden (z.B. per Navigationsmenü). Optional können z.B. auch einzelne geschützte Ressourcen nach der Anmeldung automatisch aufgerufen werden.

Will nun der Benutzer über den Portaldienst [220] auf eine geschützte Ressource zugreifen, z.B. per Klick im Navigationsmenü, so beginnt der Single Sign-On Prozeß: Der Browser [100] wird vom SSO Provider Dienst [230] auf den dezentralen Single Sign-On Agent Dienst (SSO Agent) [310] verwiesen und übergibt diesem verschiedene Anmeldeinformationen einschließlich der digitalen Signatur des SSO Provider Dienstes [230].

Diese Datenübergabe kann z.B. als URI-Parameter geschehen.

Die Einbeziehung des SSO Provider Dienstes kann bereits bei Erzeugung des Navigationsmenüs (o.ä.) geschehen, so daß der im Navigationsmenü (o.ä.) enthaltene Link bereits alle Informationen enthält. Alternativ kann das Navigationsmenü (o.ä.) intern zunächst auf den SSO Provider Dienst [230] verweisen, und erst dieser zum SSO Agent [310] weiterleiten. Weitere Varianten sind denkbar, etwa die Implementierung des SSO Provider Dienst [310] als Reverse Proxy vor dem Portaldienst, wobei der Portaldienst den Browser per HTTP Redirect zum SSO Agenten verweist, jedoch dieser Redirect durch den SSO Provider Dienst [310] manipuliert, nämlich um die nötigen Anmeldeinformationen ergänzt wird.

Anmeldeinformationen sind vor allem Benutzeridentität, eine eindeutige Kennung der gewünschten geschützten Ressource ("Ressourcen-ID"), Gültigkeitsfrist (z.B. als Zeit/Datumsangabe) der Anmeldeinformationen sowie die digitalen Signatur des SSO Provider Dienstes [230]. Letztere wird durch ein digitales Signaturverfahren, z.B. RSA mit MD5 und X.509-Zertifikaten, gebildet, welches auf die anderen Anmeldeinformationen angewandt wird. Weitere Anmeldeinformationen, etwa Art der Anfrage, Version o.ä., sind möglich. Falls das gewählte Signaturverfahren für die gewählte Datenübergabe keinen geeigneten Datenstrom erzeugt, kann die Signatur zunächst mit einer geeigneten Technik reversibel aufbereitet werden (z.B. bin2hex, base64, URLencode, uuencode, ... bzw. Kombinationen davon).

Der SSO Agent Dienst [310] nimmt die ankommende Anfrage an und überprüft die enthaltenen Sicherheitsinformationen. Zu diesem Zweck wird zunächst die digitale Signatur mit dem verwendeten Verfahren sowie dem öffentlichen Schlüssel des SSO Provider Dienstes [230] verifiziert.

Sodann wird geprüft, daß die Gültigkeitsfrist noch nicht überschritten ist. Dazu sind ggf. Synchronisation der Uhren von SSO Provider [230]und SSO Agent [310] und je nach Implementierung auch Abstimmung der Zeitzonen sicherzustellen. Alternativ können z.B. Verfahren zum periodischen Offsetabgleich o.ä. verwendet werden. Verfahren, die anstelle einer absoluten Gültigkeitsfrist (Bsp: "24.12.2003 23:00 UTC") mit einer relativen Gültigkeitsdauer (Bsp: "90 Sekunden") arbeiten, erfordern eine zusätzliche direkte Kommunikation zwischen SSO Provider [230] und SSO Agent [310] und sollten zudem die Einmaligkeit einer Signatur sicherstellen, etwa durch Einfügen eines zusätzlichen absoluten Zeitstempels oder eines Zählers. Andere Umsetzungen der Gültigkeitsfristprüfung sind denkbar.

Schließlich kann optional die Einmaligkeit der Anfrage geprüft werden (Wiedereinspielschutz). Zu diesem Zweck speichert der SSO Agent [310] alle verwendeten Anmeldeinformationen einschließlich ihrer Signatur zwischen und löscht sie erst nach Ablauf ihrer Gültigkeitsfrist. Bei Eintreffen einer neuen Anfrage wird dann in diesem Zwischenspeicher geprüft, ob dieselben Anmeldeinformationen bereits verwendet wurden. Andere Umsetzungen des Wiedereinspielschutzes sind denkbar.

Wurden die Sicherheitsinformationen der Anfrage für gültig befunden, so ruft der SSO Agent [310] den Sitzungsinitialisierungsdienst [320] der gewünschten geschützten Ressource auf. Dies geschieht anhand der in den Anmeldeinformationen übergebenen Ressourcen-ID sowie den zugehörigen Aufrufinformationen, die lokal z.B. in einer Konfigurationsdatei des SSO Agent [310] hinterlegt sind. Ist die übergebene Ressourcen-ID nicht hinterlegt, so wird die Anfrage als ungültig behandelt.

Der Aufruf des Sitzungsinitialisierungsdienst [320] kann z.B. als Kommandozeilenaufruf implementiert werden, jedoch auch über andere Wege wie z.B. Pipes oder gar Sockets. Alternativ können SSO Agent und Sitzungsinitialisierungsdienst auch integriert realisiert werden, d.h. der Aufruf erfolgt dann durch Methoden- oder Funktionsaufruf o.ä.

Mit dem Aufruf ist der in den Anmeldeinformationen enthaltene Benutzername zu übergeben. Optional können weitere Parameter übergeben werden, etwa die IP-Adresse oder die Version des Browsers [100] u.ä. Zudem kann, sofern der Sitzungsinitialisierungsdienst als separates Programm implementiert wird, ein zusätzlicher Schutzmechanismus zur Verhinderung oder Erschwerung des unberechtigten manuellen Aufrufs hinzugefügt werden (z.B. Verschlüsselung, Verschleierung, Signaturverfahren).

Der aufgerufene Sitzungsinitialisierungsdienst [320] der geschützten Ressource erzeugt nun eine Benutzersitzung ("Session") o.ä. für den empfangenen Benutzernamen und übergibt eine URI ("Redirect-URI") sowie alle weiteren nötigen Informationen zurück zum SSO Agent [310], welcher sie per HTTP Redirect zum Browser zurückgibt. Die Redirect-URI führt den Browser so zur geschützten Ressource [330], als wenn er sich zuvor direkt an dieser angemeldet hätte. Zu den o.g. weiteren nötigen Informationen können z.B. Session-ID o.ä. gehören. Die Informationen können in dem von der geschützten Ressource erwarteten Format (z.B. per URI-Parameter oder Cookie) übergeben werden.

Optional kann der Sitzungsinitialisierungsdienst [320] weitere Funktionen und Prüfungen wahrnehmen, etwa die Beschränkung des Single Sign-On Zugriffs auf bestimmte Benutzer oder – Gruppen oder das Setzen einer Markierung, um Änderungen innerhalb der geschützten Ressource [330] (etwa des Verbergens der Kennwortänderungsfunktion) zu aktivieren.

Sofern ein zusätzlicher Schutzmechanismus für den Aufruf des Sitzungsinitialisierungsdienstes [320] auf Seiten des SSO Agent [310] implementiert wurde, muß dieser naturgemäß auch vom Sitzungsinitiaüsierungsdienst [320] unterstützt und ausgewertet werden.

Der Sitzungsinitialisierungsdienst ist spezifisch für die geschützte Ressource bereitzustellen, entweder vom Hersteller bezogen oder durch sonstige Programmierleistung, wobei Kenntnisse über die Sitzungsverwaltung der geschützten Ressource erforderlich sind. Eine Ausnahme bilden geschützte Ressourcen, die einen dritten Single Sign-On Mechanismus unterstützen oder die auf eine Single Sign-On – fähige Plattform aufsetzen (etwa auf einen Java Application Server). Hier kann ein generischer Sitzungsinitialisierungsdienst für jenen dritten Single Sign-On Mechanismus verwendet bzw. entwickelt werden, sofern letzterer vertrauensbasiert arbeiten kann (also nicht zwingend Kennwort oder vergleichbare Zugangsdaten erfordert.)

Da der Benutzername eines Benutzers in verschiedenen geschützten Ressourcen unterschiedlich sein kann, kann für diesen Fall im SSO Provider Dienst [230] ein ergänzendes Benutzerumsetzungsverfahren ("User Mapping") implementiert werden, welches anhand einer Tabelle den in der gewünschten geschützten Ressource hinterlegten Namen als Benutzeridentität in die Anmeldeinformationen einsetzt.

Für ergänzende Sicherungsmaßnahmen und Funktionalitäten kann zudem eine zusätzliche Kommunikationsbeziehung implementiert werden, nämlich zwischen SSO Provider [230] und SSO Agent [310]. Dabei werden beim Erzeugen der Signatur für die Anmeldeinformationen ebendiese Daten direkt an den SSO Agent [310] übermittelt. Dies kann z.B. zur Übermittlung der Browser-IP, zur Zeitabgleich, zur Logout-Koordination u.v.m. genutzt werden. Das Verfahren zur Prüfung der Einmaligkeit der Anfrage (Wiedereinspielschutz) kann ggf. integriert werden.

Bei der Implementierung ist zu beachten, daß verschiedene begleitende Schutzmaßnahmen ergriffen werden sollten (etwa die Verwendung von SSL für die Übermittlung des Redirects vom Portal/SSO Provider zum Browser), auf die jedoch hier nicht eingegangen werden soll.

Ausführungsbeispiel
Ein Ausführungsbeispiel der Erfindung soll deren Funktion und einfache Umsetzbarkeit exemplarisch darstellen. Es sei nochmals betont, daß andere Implementierungen insbesondere hinsichtlich Integration der Dienste sowie optionaler Erweiterungen variieren kann.
Als Portalservice wird die in der Sprache PHP geschriebene Open Source – Software "Typo3" (www.typo3.com) verwendet, und auch deren Authentisierungsdienst wird genutzt. Der SSO Provider ist als Erweiterung ("Extension") innerhalb von Typo3 realisiert.
Die exemplarische zu schützende Ressource ist das Problemverfolgungswerkzeug "OTRS" (www.otrs.org), welches ebenfalls Open Source – Software ist, allerdings in der Sprache Perl programmiert.
Der SSO Agent ist als PHP-Programm in Verbindung mit einem "Apache"-Webserver implementiert.
Der Sitzungsinitialisierungsdienst ist als Kommandozeilenaufruf implementiert, wobei der Programmcode eine leicht abgeänderte Kopie eines OTRS-Moduls ist.
Zur Signatur wird die Software "OpenSSL" (www.openssl.org) in Verbindung mit X.509-Zertifikaten und RSA/MD5 Signaturalgorithmus verwendet.
Im Typo3-basierten Portal wird für angemeldete berechtigte Benutzer der Menüpunkt "OTRS" angezeigt (die rollenbasierte Darstellung ist eine Standardfunktionalität der Portalsoftware).
In der zentralen Konfiguration des SSO Providers sind der privater Signaturschlüssel sowie optional ein Kennwort ("Passphrase") hinterlegt.
In der Konfiguration des OTRS-Zugriffs im SSO Provider sind alle spezifischen Daten hinterlegt, vor allem die URI des SSO Agent (z.B. "http://server2.naw.de") und die ID der geschützten Ressource (z.B. "otrscustomer"), optional weitere wie Gültigkeitsdauer der Anfrage sowie Darstellungsparameter, Beschreibungstext u.ä.
Klickt der Benutzer nun auf den Menüpunkt "OTRS", so wird der SSO Provider mit den o.g. OTRS-spezifischen Parametern aufgerufen, welche die nötigen Anmeldeinformationen zusammenstellt. Die Gültigkeitsfrist wird hier als aktuelle Zeit zuzüglich (konfigurierte oder Standard-) Gültigkeitsdauer ermittelt und als absoluter Wert im "time()" – Format (also Sekunden seit dem 1.1.1970, 0:00:00 UTC) angegeben.
Schließlich wird die Signatur über alle Parameter berechnet. Das Ergebnis von 128 Byte Binärdaten wird nun zunächst browsergerecht in ASCII-Zeichen umgewandelt, in diesem Falle durch hexadezimale Darstellung per bin2hex() Funktion.
Schließlich werden die URI des SSO Agent sowie die Anmeldeinformationen einschließlich der Signatur zu einer URI kombiniert und diese per HTTP Redirect zum Browser übermittelt, z.B.:
Der Browser folgt nun diesem HTTP Redirect und ruft durch die übergebene URI den SSO Agent auf.
Dieser verfügt über eine lokale Konfigurationsdatei, die sowohl globale als auch spezifische Parameter enthält, z.B.:
Der SSO Agent wertet nun die erhaltenen Parameter aus. Zu diesem Zweck überprüft er zunächst die Unterschrift anhand des hinterlegten öffentlichen Schlüssels des SSO Providers, ebenfalls unter Verwendung von OpenSSL. Anschließend wird die lokale Zeit mit der in den Anmeldeinformationen angegebenen Gültigkeitsfrist verglichen. Schließlich wird geprüft, ob die empfangene Signatur bereits in der Datei "usedtokens" vorhanden ist, was nicht der Fall sein darf.
Sind alle Prüfungen positiv verlaufen, so werden die Anmeldedaten einschließlich Signatur in der Datei "usedtokens" abgelegt. Im gleichen Zuge werden dort enthaltene veraltete Anmeldedaten (also mit abgelaufener Gültigkeitsfrist) aus der Datei gelöscht.
Nun ruft der SSO Agent den passenden Sitzungsinitialisierungsdienst auf. Dazu wird in der Konfigurationsdatei nach der empfangenen Ressourcen-ID (hier "otrscustomer") gesucht und der dafür hinterlegte Ausdruck angewendet. Dieser Ausdruck kann neben festen Bestandteilen auch verschiedene definierte Variablen enthalten, die zum Zeitpunkt des Aufrufs durch den zugehörigen Wert ersetzt werden. Im o.g. Beispiel würde die Variable "%user%" durch den empfangenen Benutzernamen ("john") ersetzt. Neben diesen Werten können auch andere Daten als Parameter übergeben werden, z.B. die IP des Browsers oder dessen Version.
Der in der Konfiguration fest hinterlegte URI-Pfad zeigt an, wohin der spätere HTTP Redirect zeigen soll. Dieser Wert kann vom Sitzungsinitialisierungsdienst potentiell verändert oder ergänzt werden und wird daher zunächst an diesen übergeben ("--url=http://server2.naw.de/customer.pl").
Der Sitzungsinitialisierungsdienst schließlich, im Beispiel das Perl-Skript "custsso.pl", initialisiert in der geschützten Ressource (hier OTRS) eine Benutzersitzung (Session) für den empfangenen Benutzernamen und ermittelt die zugehörige Sitzungskennung (Session ID). Diese sowie etwaige weitere Werte werden zur Übergabe an den Browser aufbereitet. Im Beispiel erfordert die Anwendung (OTRS) die Session ID sowohl in der URI als auch als Cookie, daher übergibt der Sitzungsinitialisierungsdienst im definierten Format:
Optional können zusätzliche Cookie-Parameter ("webpath" u.a.) sowie weitere Cookies übergeben werden. Damit können unterschiedliche Funktionsweisen anderer Anwendungen hier berücksichtigt werden.
Schließlich wertet der SSO Agent die Rückgabezeilen aus und sendet die Werte (als Antwort auf die ursprüngliche Anfrage des Browsers) per HTTP Redirect zum Browser, welcher nun auf die geschützte Ressource zugreifen kann – als ob sich der Benutzer direkt am System angemeldet hätte.
Vorteile
Mit der vorliegenden Lösung steht ein Verfahren zur Verfügung, die an Flexibilität und Einfachheit den Stand der Technik übertrifft.
Einerseits ist die Einbindung des Verfahrens in eine bestehende oder neue (ggf. geographisch verteilte) Serverlandschaft nahezu restriktionsfrei möglich, zumal die beschriebene Lösung in verschiedener Weise implementiert werden kann (ohne oder mit Reverse Proxy,...).
Durch die Verwendung eines vertrauensbasierten Verfahrens, nämlich der Signatur der Identität durch eine zentrale Instanz, wird auf die Handhabung von jeglicher Zugangskennungen, im Klartext oder reversibel verschlüsselt, verzichtet. Dies bringt Sicherheitsvorteile (keine Möglichkeit der Gewinnung eines Klartextpaßworts für einen Angreifer), Implementierungsvorteile (keine Notwendigkeit zur Synchronisierung von Benutzerzugangsdaten) und erleichtert das Handling (z.B. Schlüsselwechsel im laufenden Betrieb möglich). Umgekehrt ist es naturgemäß auch beim vorliegenden Verfahren von großer Wichtigkeit, potentielle Angriffspunkte zu kennen und zu schützen. Zu nennen sind vor allem der Zugang zum Sitzungsinitialisierungsdienst, das Benutzerzuordnungsverfahren ("User Mapping") und der private Schlüssel des SSO Providers.
Die Möglichkeit der SSO-Datenübergabe per URI bietet eine bislang nicht gekannte Flexibilität und Einfachheit in der Implementierung.

Claims

Verfahren zum Single Sign-On an webbasierten Anwendungen über ein gemeinsames Auswahlmenü, dadurch gekennzeichnet, daß die Identität des Benutzers sowie weitere Daten von einem zentralen System (z.B. Portal) bzw. einem angegliederten zentralen Dienst signiert, zum Browser und von dort an die aufgerufene dezentrale Anwendung übergeben werden, welche die Benutzeridentität damit als gegeben anerkennt.
Verfahren zum Single Sign-On nach Patentanspruch 1, dadurch gekennzeichnet, daß die zum Single Sign-On erforderlichen Anmeldedaten, insbesondere die Identität des Benutzers sowie Sicherheitsmerkmale, als URI-Parameter übergeben werden.