Authentifizierung
Die für die Liberty-Sicherheit erforderliche Authentifizierung besteht darin, die Identität eines Benutzers zu bestätigen.
Um auf eine geschützte Webressource zugreifen zu können, muss der Benutzer Berechtigungsnachweisdaten wie Benutzer-ID und Kennwort angeben. Der Authentifizierungsprozess umfasst die Erfassung dieser Benutzerberechtigungsnachweisdaten (basierend auf der Konfiguration der Erfassung dieser Daten in der Webanwendung) und die Validierung dieser Daten anhand der konfigurierten Registry. Nach der Verifizierung der Berechtigungsnachweisdaten wird ein JAAS-Subjekt für diesen Benutzer erstellt. Das Subjekt enthält weitere Informationen zum Benutzer, wie z. B. die Gruppen, zu denen der Benutzer gehört, und die für den Benutzer erstellten Token. Die Informationen in diesem Subjekt werden dann während des Berechtigungsprozesses verwendet, um festzustellen, ob der Benutzer auf die Ressource zugreifen darf.
Das folgende Diagramm veranschaulicht einen typischen Authentifizierungsprozessablauf für eine Webressource.

Der Authentifizierungsprozess umfasst die Erfassung von Berechtigungsnachweisdaten des Benutzers und das Überprüfen des Cache, um festzustellen, ob das Subjekt für diesen Benutzer vorhanden ist. Wenn das Subjekt nicht vorhanden ist, ruft der Prozess den JAAS-Service auf, damit dieser die Authentifizierung durchführt und ein Subjekt erstellt. Der JAAS-Service ruft eine Reihe von Anmeldemodulen für die Durchführung der Authentifizierung auf. Abhängig von den Berechtigungsnachweisdaten wird das Subjekt von mindestens einem Anmeldemodul erstellt. Anschließend ruft das Anmeldemodul die konfigurierte Registry auf, um die Berechtigungsdaten zu validieren. Bei erfolgreicher Validierung erfasst und erstellt der Authentifizierungsprozess relevante Informationen für diesen Benutzer, einschließlich der Gruppen, zu denen der Benutzer gehört, und des SSO-Tokens (Single Sign-on), das für die SSO-Funktion verwendet wird, und speichert diese als relevante Berechtigungsnachweise im Subjekt. Sie können die im Subjekt gespeicherten Informationen anpassen, indem Sie angepasste Anmeldemodule während dieses Prozesses einfügen.
- Benutzerregistrys
- Authentifizierungscache
- JAAS-Konfiguration
- JAAS-Anmeldemodule
- Callback-Handler
- Berechtigungsnachweise und Token
- LTPA
- OpenID
- OpenID Connect
- SPNEGO
- Eingeschränkte Kerberos-Delegierung für SPNEGO
- Single Sign-on (SSO)
- SAML-Web-Browser-SSO
- Modulare Authentifizierung
- Identitätszusicherung
- RunAs()-Authentifizierung
- Proxy-Anmeldemodul
- Anmeldung mit Zertifikat
- Anmeldemodul mit Hashtabelle
Benutzerregistrys
Bei der Validierung der Authentifizierungsdaten eines Benutzers rufen die Anmeldemodule die konfigurierte Benutzerregistry auf, um die Benutzerinformationen zu validieren. Liberty unterstützt einfache konfigurationsbasierte Benutzerregistrys und leistungsfähigere LDAP-basierte Registrys. Weitere Informationen finden Sie unter Benutzerregistry in Liberty konfigurieren.
Mit der LDAP-Registry können Sie auch mehrere Repositorys zusammenfassen und die LDAP-Operationen in zwei oder mehr Registrys ausführen. Der Liberty-Benutzer kann das Feature für die Einbindung der LDAP-Registry entweder direkt in der Datei server.xml oder im Abschnitt Einbindung der LDAP-Registry im Entwicklertool konfigurieren. Nach der Konfiguration der eingebundenen Repositorys können Sie ein konsolidiertes Ergebnis der eingebundenen Repositorys für jede auszuführende Operation abrufen. Wenn Sie beispielsweise eine Suchoperation für alle Benutzernamen ausführen möchten, die mit test beginnen, können Sie einen Suchvorgang in der Gruppe der LDAP-Registrys ausführen und das konsolidierte Suchergebnis abrufen, das daraufhin an das aufrufende Programm zurückgesendet werden kann.
Authentifizierungscache
Da die Erstellung eines Subjekts relativ aufwendig ist, stellt Liberty einen Authentifizierungscache bereit, in dem ein Subjekt nach erfolgreicher Authentifizierung eines Benutzers gespeichert werden kann. Die Standardverfallszeit für den Cache ist 10 Minuten. Wenn sich der Benutzer nicht innerhalb von 10 Minuten erneut anmeldet, wird das Subjekt entfernt und der Authentifizierungsprozess wiederholt, um ein Subjekt für diesen Benutzer zu erstellen. Änderungen an der Konfiguration, die sich auf die Erstellung des Subjekts auswirken, wie z. B. das Hinzufügen eines Anmeldemoduls oder die Änderung der LTPA-Schlüssel, führen dazu, dass der Inhalt des Authentifizierungscache gelöscht wird. Wenn das Subjekt zwischengespeichert ist und sich die Informationen in der Registry ändern, wird der Cache mit den Informationen in der Registry aktualisiert. Sie können das Cachezeitlimit und die Cachegröße konfigurieren und Sie können das Caching inaktivieren oder aktivieren. Weitere Informationen finden Sie unter Authentifizierungscache in Liberty konfigurieren.
JAAS-Konfiguration
- system.WEB_INBOUND
- Wird beim Zugriff auf Webressourcen wie Servlets und JSPs verwendet.
- WSLogin
- Wird von Anwendungen bei der programmsteuerten Anmeldung verwendet. Wird außerdem von Anwendungen verwendet, die in einem Anwendungs-Client-Container ausgeführt werden. Anders als die Konfiguration ClientContainerJAAS erkennt diese Konfiguration den Handler CallbackHandler nicht, der im Implementierungsdeskriptor des Clientanwendungsmoduls angegeben ist.
- system.DEFAULT
- Wird für die Anmeldung verwendet, wenn keine JAAS-Konfiguration angegeben ist.
- system.DESERIALIZE_CONTEXT
- Wird bei der Deserialisierung eines Sicherheitskontexts verwendet. Diese JAAS-Konfiguration führt die Authentifizierung durch, um Subjekte erneut zu erstellen, die zum Zeitpunkt der Serialisierung des Sicherheitskontexts im Thread aktiv waren. Sie können diese JAAS-Konfiguration angeben und Ihre eigenen JAAS-Anmeldemodule hinzufügen, indem Sie den JAAS-Konfigurationseintrag in der Datei server.xml bearbeiten, um sicherzustellen, dass die weitergegebenen Subjekte die von Ihnen angepassten Informationen enthalten.
- ClientContainer
- Wird von Anwendungen verwendet, die in einem Anwendungs-Client-Container ausgeführt werden. Diese JAAS-Anmeldekonfiguration erkennt den Handler CallbackHandler, der ggf. im Implementierungsdeskriptor des Clientanwendungsmoduls angegeben ist.
Es ist keine explizite Konfiguration erforderlich, sofern Sie keine Anpassung mit den angepassten Anmeldemodulen vornehmen möchten. Je nach Anforderung können Sie bestimmte Anmeldekonfigurationen anpassen. Wenn Sie beispielsweise möchten, dass alle Webressourcenanmeldungen angepasst werden, dürfen Sie angepasste Anmeldemodule nur der Konfiguration system.WEB_INBOUND hinzufügen. Weitere Informationen hierzu finden Sie unter Angepasstes JAAS-Anmeldemodul für Liberty konfigurieren.
JAAS-Anmeldemodule
Die JAAS-Konfiguration verwendet zur Erstellung des Subjekts einen Satz von Anmeldemodulen. Liberty stellt in jeder Anmeldekonfiguration einen Satz von Anmeldemodulen bereit. Das Subjekt wird je nach Authentifizierungsdaten von einem bestimmten Anmeldemodul erstellt. Die Authentifizierungsdaten werden gemäß Festlegung in der JAAS-Spezifikation über den Callback-Handler an die Anmeldemodule übergeben. Wenn beispielsweise der Callback-Handler für Benutzer-ID und Kennwort für die Authentifizierung verwendet wird, führt das Anmeldemodul userNameAndPassword die Authentifizierung durch. Wenn die Authentifizierungsdaten in Form eines SingleSignonToken bereitgestellt werden, führt nur das Anmeldemodul token die Authentifizierung durch.
- userNameAndPassword
- Führt die Authentifizierung durch, wenn ein Benutzername und ein Kennwort als Authentifizierungsdaten verwendet werden.
- certificate
- Führt die Authentifizierung durch, wenn die Authentifizierungsdaten für gegenseitiges SSL in Form eines X.509-Zertifikats bereitgestellt werden.
- token
- Führt die Authentifizierung durch, wenn die Authentifizierungsdaten in Form eines SSO-Tokens bereitgestellt werden. Während des Authentifizierungsprozesses wird ein SSO-Token erstellt und in einem Cookie an den HTTP-Client (Browser) zurückgesendet. In nachfolgenden Anforderungen wird dieses Cookie vom Browser zurückgesendet und der Server extrahiert das Token aus dem Cookie, um den Benutzer zu authentifizieren, wenn SSO aktiviert ist.
- hashtable
- Wird verwendet, wenn die authentifizierten Daten über eine vordefinierte Hashtabelle gesendet werden. Weitere Informationen zur Anmeldung über eine Hashtabelle finden Sie unter Anmeldemodul mit Hashtabelle. Dieses Anmeldemodul wird auch von der Sicherheitslaufzeit verwendet, wenn die Authentifizierung nur anhand der Identität durchgeführt wird, wie beispielsweise im Fall von runAs.
- proxy
- Das Standardanmeldemodul für WSLogin. Nähere Informationen hierzu finden Sie unter Proxy-Anmeldemodul.
Die Anmeldemodule werden in der Reihenfolge aufgerufen, in der sie konfiguriert wurden. Die Standardreihenfolge ist hashtable, userNameAndPassword, certificate, token. Wenn Sie den Anmeldeprozess mit angepassten Anmeldemodulen anpassen müssen, können Sie diese Module in der erforderlichen Reihenfolge bereitstellen und konfigurieren. Gewöhnlich geben Sie ein angepasstes Modul als erstes Modul in der Liste der Anmeldemodule an, damit dieses Modul zuerst aufgerufen wird. Wenn ein angepasstes Anmeldemodul verwendet wird, müssen Sie alle Anmeldemodulinformationen zusammen mit dem angepassten Anmeldemodul in der gewünschten Reihenfolge in der Konfiguration angeben.
Wenn ein Anmeldemodul feststellt, dass es die Authentifizierung durchführen kann, stellt es zunächst sicher, dass die übergebenen Authentifizierungsdaten gültig sind. Für die Authentifizierung mit Benutzernamen und Kennwort wird beispielsweise die konfigurierte Benutzerregistry aufgerufen, um die Authentifizierungsdaten zu verifizieren. Für die Tokenauthentifizierung muss das Token entschlüsselt werden und gültig sein, damit die Verifizierung erfolgreich ist.
Nach der Validierung der Authentifizierungsdaten erstellen die Anmeldemodule Berechtigungsnachweise mit zusätzlichen Daten für den Benutzer, einschließlich Gruppen und dem SSO-Token. Ein angepasstes Anmeldemodul kann dem Subjekt zusätzliche Daten hinzufügen, indem es eigene Berechtigungsnachweise erstellt. Damit die Berechtigung in Liberty funktioniert, muss das Subjekt die Berechtigungsnachweise WSCredential, WSPrincipal und SingleSignonToken enthalten. Der Berechtigungsnachweis WSCredential enthält die Gruppeninformationen mit zusätzlichen Informationen, die die Sicherheitslaufzeitumgebung benötigt.
Callback-Handler
Liberty unterstützt verschiedene Callback-Handler für die Bereitstellung von Daten für die Anmeldemodule während des JAAS-Authentifizierungsprozesses. Ein angepasstes Anmeldemodul kann die Callback-Handler-Informationen verwenden, um sich selbst zu authentifizieren. Wenn der Callback-Handler beispielsweise auf Informationen in einem HttpServletRequest-Objekt zugreifen muss, kann er dazu diesen spezifischen Callback-Handler verwenden.
- com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl
- com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory
Weitere Informationen hierzu finden Sie unter Angepasste JAAS-Anmeldemodule für eine Systemanmeldekonfiguration entwickeln.
Berechtigungsnachweise und Token
Wie im Abschnitt loginModule beschrieben, werden Berechtigungsnachweise im Rahmen des Subjekterstellungsprozesses erstellt. Liberty erstellt die Berechtigungsnachweise WSCredential, SingleSignonToken und WSPrincipal. Der Berechtigungsnachweis SingleSignonToken enthält das Token, das in einem Cookie an den Browser zurückgesendet wird, damit SSO funktioniert. Dieses Token enthält die Benutzerinformationen und eine Verfallszeit. Es wird mit den beim ersten Serverstart generierten LTPA-Schlüsseln (Lightweight Third Party Authentication) signiert und verschlüsselt. Die Standardverfallszeit ist 2 Stunden und eine absolute Zeit, die nicht auf Benutzeraktivitäten basiert. Nach Ablauf der 2 Stunden verfällt das Token und der Benutzer muss sich erneut anmelden, um auf die Ressource zugreifen zu können.
LTPA
LTPA ist für verteilte Umgebungen mit mehreren Anwendungsservern bestimmt. In Liberty unterstützt LTPA SSO und Sicherheit in einer verteilten Umgebung durch Kryptografie. Diese Unterstützung ermöglicht LTPA, authentifizierungsrelevante Daten zu verschlüsseln, digital zu signieren und sicher zu übertragen und die Signatur später zu entschlüsseln und zu prüfen.
Anwendungsserver können über das LTPA-Protokoll sicher kommunizieren. Außerdem wird das SSO-Feature (Single Sign-on) bereitgestellt, bei dessen Verwendung sich ein Benutzer nur authentifizieren muss, wenn er eine Verbindung zu einem Domain Name System (DNS) herstellt. Anschließend kann der Benutzer auf Ressourcen in anderen Liberty-Servern in derselben Domäne zugreifen, ohne zur Eingabe von Berechtigungsnachweisen aufgefordert zu werden. Bei den Realmnamen auf jedem System in der DNS-Domäne muss die Groß-/Kleinschreibung beachtet werden und die Realmnamen müssen exakt übereinstimmen.
Das LTPA-Protokoll verwendet Chiffrierschlüssel, um Benutzerdaten, die zwischen Servern übergeben werden, zu verschlüsseln und zu entschlüsseln. Diese Schlüssel müssen von verschiedenen Servern gemeinsam genutzt werden, damit die Ressourcen auf einem Server auf die Ressourcen auf anderen Servern zugreifen können, sofern alle beteiligten Server dieselbe Benutzerregistry verwenden. LTPA erfordert, dass die konfigurierte Benutzerregistry ein zentral genutztes Repository ist, sodass Benutzer und Gruppen in allen Servern identisch sind.
Wenn Sie LTPA verwenden, wird ein Token erstellt, das die Benutzerdaten und eine Verfallszeit enthält und mit den Schlüsseln signiert wird. Das LTPA-Token ist zeitspezifisch. Uhrzeit und Datum aller teilnehmenden Server müssen synchronisiert sein. Wenn dies nicht der Fall ist, verfallen LTPA-Token vorzeitig, was zu Fehlern bei der Authentifizierung oder Validierung führt. Standardmäßig wird die koordinierte Weltzeit (UTC, Coordinated Universal) verwendet, und alle anderen Server müssen dieselbe UTC-Zeit haben. Wie Sie sicherstellen können, dass auf allen Servern dieselbe UTC-Zeit verwendet wird, können Sie in der Dokumentation zu Ihrem Betriebssystem nachlesen.
Das LTPA-Token wird über Cookies für Webressourcen an andere Server übergeben, wenn SSO aktiviert ist.
Wenn die Empfangsserver dieselben Schlüssel wie der Ursprungsserver verwenden, kann das Token entschlüsselt werden, um die Benutzerdaten zu erhalten. Die Benutzerdaten werden dann validiert, um sicherzustellen, dass das Token nicht abgelaufen ist und dass die Benutzerdaten im Token in der zugehörigen Registry gültig sind. Bei erfolgreicher Validierung sind die Ressourcen in den Empfangsservern nach der Berechtigungsprüfung zugänglich.
Jeder Server muss gültige Berechtigungsnachweise haben. Wenn die Berechtigungsnachweise ablaufen, muss der Server zur Authentifizierung mit der Benutzerregistry kommunizieren. Die Verlängerung der Verweildauer eines LTPA-Tokens im Cache stellt ein geringfügig höheres Sicherheitsrisiko dar, das bei der Definition der Sicherheitsrichtlinien berücksichtigt werden muss.
Wenn eine gemeinsame Nutzung von Schlüsseln durch verschiedene Liberty-Server erforderlich ist, kopieren Sie die Schlüssel von einem Server auf einen anderen. Aus Sicherheitsgründen werden die Schlüssel mit einem zufällig generierten Schlüssel verschlüsselt und mit einem benutzerdefinierten Kennwort geschützt. Dasselbe Kennwort muss beim Import der Schlüssel in einen anderen Server verwendet werden. Das Kennwort wird nur für den Schutz der Schlüssel verwendet und nicht zum Generieren der Schlüssel.
Wenn die Sicherheit aktiviert ist, wird LTPA standardmäßig während des Starts des Liberty-Servers konfiguriert. Weitere Informationen zur LTPA-Unterstützung finden Sie unter LTPA in Liberty konfigurieren.
OpenID
OpenID ist ein offener Authentifizierungsstandard, der Benutzern die Möglichkeit bietet, sich bei mehreren Entitäten zu authentifizieren, ohne mehrere Konten oder Gruppen von Berechtigungsnachweisen verwalten zu müssen. Liberty unterstützt den Standard OpenID Authentication 2.0 in der Funktion als Relying Party. In diesem Standard setzt eine Relying Party eine Authentifizierungsbestätigung eines OpenID-Providers voraus. Anstatt der Relying Party Berechtigungsnachweise bereitzustellen, werden Benutzer zur Übergabe ihrer Berechtigungsnachweise an den OpenID-Provider umgeleitet. Der OpenID Provider bestätigt das Authentifizierungsergebnis mit der Relying Party und gibt eine eindeutige Kennung zurück, die dem Eigner gehört, möglicherweise zusätzlich zu einem Teil persönlicher Daten, die vom Benutzer genehmigt wurden, wie z. B. der Name oder die E-Mail-Adresse des Benutzers. Die Relying Party kann diese Daten dann verwenden, um die Authentifizierung ohne Verarbeitung der Benutzerberechtigungsnachweise durchzuführen. Darüber hinaus können Benutzer ein einziges Konto bei einem OpenID Provider verwenden, um sich selbst bei jeder als Relying Party agierenden Entität zu authentifizieren, ohne gesonderte Konten für jede einzelne Entität verwalten oder erstellen zu müssen.
Weitere Informationen zu OpenI finden Sie unter OpenID. Informationen zum Konfigurieren von OpenID in einem Liberty-Server finden Sie unter OpenID-Relying-Party in Liberty konfigurieren.
OpenID Connect
OpenID Connect ist ein einfaches Identitätsprotokoll und ein offener, auf dem Protokoll OAuth 2.0 basierender Standard. OpenID Connect ermöglicht Clientanwendungen, sich auf eine Authentifizierung zu stützen, die von einem OpenID Connect-Provider zur Prüfung einer Benutzeridentität durchgeführt wird.
Clientanwendungen können auch grundlegende Informationen zum Profil eines Benutzers mit einem kompatiblen und REST-konformen Verfahren von OpenID Connect-Providern abrufen. Die Unterstützung für OpenID Connect basiert auf OpenID Connect Standard v1.0.
Weitere Informationen zu OpenID Connect finden Sie unter OpenID Connect. Informationen zum Konfigurieren eines OpenID Connect-Clients oder einer Relying Party in einem Liberty-Server finden Sie unter OpenID Connect-Client in Liberty konfigurieren. Informationen zum Konfigurieren eines OpenID Connect-Providers in einem Liberty-Server finden Sie unter OpenID Connect-Provider in Liberty konfigurieren.
SPNEGO
Mithilfe des SPEGNO-Mechanismus (Simple and Protected GSS-API Negotiation) erhalten Benutzer mit einer einzigen Anmeldung am Microsoft-Domänencontroller Zugriff auf geschützte Anwendungen auf Liberty-Servern und werden anschließend nicht mehr zur Angabe ihrer Berechtigungsnachweise aufgefordert.
Wenn die SPNEGO-Webauthentifizierung aktiviert ist und ein Browser-Client oder ein Nicht-Browser-Client auf eine geschützte Ressource im
Liberty-Server zugreift, authentifiziert SPNEGO den Zugriff auf die geschützte Ressource in der HTTP-Anforderung. Ein Browser-Client erstellt ein SPNEGO-Token. Ein Nicht-Browser-Client erstellt ein Kerberos-Service-Ticket (Kerberos-Token). Der Client sendet das Token im Rahmen der HTTP-Anforderung an den Liberty-Server. WebSphere Application Server ruft die Benutzeridentität vom SPNEGO- bzw. Kerberos-Token ab und validiert sie. Mit dieser Identität wird ein sicherer Kontext zwischen dem Benutzer und dem Anwendungsserver
etabliert.
Weitere Informationen zu SPNEGO finden Sie unter Single Sign-on für HTTP-Anforderungen mit SPNEGO-Webauthentifizierung. Weitere Informationen zum Konfigurieren von SPNEGO im Liberty-Server finden Sie unter SPNEGO-Authentifizierung in Liberty konfigurieren.
Eingeschränkte Kerberos-Delegierung für SPNEGO
Das Kerberos-Feature für eingeschränkte Delegierung stellt zwei APIs bereit, die zum Erstellen von SPNEGO-Ausgangstokens für Back-End-Services verwendet werden, die die SPNEGO-Authentifizierung unterstützten, wie z. B. .NET-Server und andere Liberty-Server.
- S4U2self
Mit dieser Erweiterung kann ein Liberty-Server ein Service-Ticket an sich selbst für einen Benutzer anfordern. Hierzu kann jede Form der Authentifizierung, die von Liberty unterstützt wird, verwendet werden. S4U2self ist die Kerberos-Erweiterung für Protokollübergang.
- S4U2proxy
Mit dieser Erweiterung kann ein Liberty-Server Service-Tickets an anerkannte Services für einen Benutzer anfordern. Diese Service-Tickets werden mit dem Service-Ticket des Benutzers an den Liberty-Service angefordert. Die Services werden vom Kerberos-KDC-Administrator (Key Distribution Center) eingeschränkt. S4U2proxy ist die Kerberos-Erweiterung für eingeschränkte Delegierung.
Single Sign-on (SSO)
SSO ermöglicht Benutzern, sich an einer Stelle (z. B. einem Server) anzumelden und auf Anwendungen auf anderen Servern zuzugreifen, ohne erneut zur Anmeldung aufgefordert zu werden. Damit SSO funktioniert, müssen die LTPA-Schlüssel zwischen den verschiedenen Liberty-Servern ausgetauscht werden, die Benutzerregistrys müssen dieselben sein, und das Token darf nicht verfallen sein. Für den Austausch der LTPA-Schlüssel können Sie die Datei ltpa.keys von einem Server auf einen anderen kopieren und den Server erneut starten, damit die neuen LTPA-Schlüssel verwendet werden. Die von allen an der SSO-Domäne teilnehmenden Servern verwendeten Registrys müssen identisch sein.
Wenn ein Benutzer in einem Liberty-Server authentifiziert wurde, wird das für den Benutzer während des Authentifizierungsprozesses generierte SSO-Token in das Cookie eingefügt, das an den HTTP-Client, z. B. einen Browser, gesendet wird. Wenn dieser Client eine weitere Anforderung für den Zugriff auf eine andere Anwendungsgruppe in einem anderen Server, aber in demselben DNS (Domain Name System), das in der SSO-Konfiguration des ersten Servers konfiguriert wurde, sendet, wird das Cookie zusammen mit der Anforderung gesendet. Der Empfangsserver versucht, den Benutzer anhand des Tokens im Cookie zu authentifizieren. Wenn beide Bedingungen erfüllt sind, validiert der Empfangsserver das Token und erstellt basierend auf dem Benutzer in diesem Server ein Subjekt, ohne den Benutzer aufzufordern, sich erneut anzumelden. Kann das Token nicht validiert werden (weil es beispielsweise aufgrund einer Abweichung bei den LTPA-Schlüsseln nicht entschlüsselt oder verifiziert werden kann), wird der Benutzer aufgefordert, die Berechtigungsnachweisdaten erneut einzugeben.
Alle Anwendungen, in denen die Verwendung des Attributs Form-login konfiguriert ist, erfordern die Konfiguration von SSO für diesen Server. Wenn der Benutzer für form-login authentifiziert wird, wird das Token an den Browser zurückgesendet, wo es dann für die Berechtigung des Benutzers beim Zugriff auf die Ressource verwendet wird.
Weitere Informationen hierzu finden Sie unter SSO-Konfiguration mit LTPA-Cookies in Liberty anpassen.
SAML-Web-Browser-SSO
Mit SAML-Web-Browser-SSO können Webanwendungen die Authentifizierung von Benutzern an einen SAML-Identitätsprovider delegieren, anstatt dafür eine konfigurierte Benutzerregistry zu verwenden.
Weitere Informationen zur Konfiguration von SAML-Web-Browser-SSO im Liberty-Server finden Sie unter SAML 2.0-Web-Browser-SSO.
Modulare Authentifizierung
- Bereitstellung eines angepassten Anmeldemoduls. Der größte Teil des Authentifizierungsprozesses stützt sich auf JAAS-Anmeldemodule. Deshalb können Sie angepasste Anmeldemodule vor, hinter oder zwischen den Anmeldemodulen einfügen, die von Liberty bereitgestellt werden. Weitere Informationen hierzu finden Sie unter Angepasstes JAAS-Anmeldemodul für Liberty konfigurieren.
- Implementierung eines Trust-Association-Interceptors (TAI) für die Verarbeitung aller Authentifizierungen, die auf Webressourcen basieren. Informationen hierzu finden Sie unter Angepassten TAI für Liberty entwickeln.
Weitere Informationen zum JAAS-Anmeldemodul und zu TAI finden Sie unter Advanced authentication in WebSphere Application Server.
Identitätszusicherung
Neben der Authentifizierung, die erfordert, dass eine anfordernde Entität ihre Identität nachweist, unterstützt Liberty auch die Identitätszusicherung. Dies ist eine gelockerte Form der Authentifizierung, die keinen Identitätsnachweis erfordert, sondern die Identität basierend auf einer Vertrauensbeziehung zu der Entität, die für die zugesicherte Identität bürgt, akzeptiert.
- Melden Sie sich über Hashtabellen an. Weitere Informationen hierzu finden Sie unter Angepasste JAAS-Anmeldemodule für eine Systemanmeldekonfiguration entwickeln.
- Verwenden Sie IdentityAssertionLoginModule. Sie können einer Anwendung oder einem
Systemprovider ermöglichen, eine Identität durch Validierung der Vertrauensbeziehung zuzusichern.
Wenn Sie das Modul IdentityAssertionLoginModule verwenden möchten, verwenden Sie das
JAAS-Anmeldeframework, in dem die Validierung der Vertrauensbeziehung in einem
angepassten Anmeldemodul und die Erstellung der Berechtigungsnachweise
im Modul IdentityAssertionLoginModule durchgeführt wird. Sie können die beiden Anmeldemodule
verwenden, um eine
JAAS-Anmeldekonfiguration zu erstellen, die zur Zusicherung einer Identität verwendet werden kann.
Die folgenden beiden angepassten Anmeldemodule sind erforderlich:Informationen hierzu finden Sie unter Anwendungsanmeldung zur Durchführung einer Identitätszusicherung mit JAAS anpassen.
- Benutzerimplementiertes Anmeldemodul (Validierung der Vertrauensbeziehung)
- Das benutzerimplementierte Anmeldemodul führt alle Aktionen aus, die der Benutzer
für die Validierung der Vertrauensbeziehung voraussetzt.
Nachdem die Vertrauensbeziehung verifiziert wurde, müssen der Vertrauensverifizierungsstatus
und die Anmeldeidentität mit dem Status für gemeinsame Nutzung in eine Map des
Anmeldemoduls eingefügt werden, sodass das Anmeldemodul für die Erstellung der Berechtigungsnachweise diese
Informationen verwenden kann.
Speichern Sie diese Map in der folgenden Eigenschaft:
Diese Eigenschaft setzt sich aus den folgenden Eigenschaften zusammen:com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
Diese Eigenschaft wird bei Anerkennung der Vertrauensbeziehung auf true gesetzt, andernfalls auf false.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
Diese Eigenschaft enthält den Principal der Identität.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
Diese Eigenschaft enthält das Zertifikat der Identität.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
- Anmeldemodul für Identitätszusicherung (Erstellung der Berechtigungsnachweise)
- Das folgende Modul erstellt den Berechtigungsnachweis:
Dieses Modul stützt sich auf die Informationen zur Vertrauensbeziehung im Status für gemeinsame Nutzung des Anmeldekontexts.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule
Das Anmeldemodul für die Identitätszusicherung sucht die Informationen zur Vertrauensbeziehung in der Eigenschaft für den Status für gemeinsame Nutzung:
Diese Eigenschaft enthält den Anerkennungsstatus und die Identität für die Anmeldung und muss die folgende Eigenschaft enthalten:com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
Diese Eigenschaft wird bei Anerkennung der Vertrauensbeziehung auf true gesetzt, andernfalls auf false.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
Diese Eigenschaft enthält den Principal der Identität für die Anmeldung, sofern ein Principal verwendet wird.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
Diese Eigenschaft enthält ein Array einer Zertifikatskette, die die Identität für die Anmeldung enthält, wenn ein Zertifikat verwendet wird.com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
Es wird eine Nachricht des Typs WSLoginFailedException zurückgegeben, wenn die Informationen zum Status, zur Vertrauensbeziehung und zur Identität fehlen. Das Anmeldemodul meldet sich dann mit der Identität an und das Subjekt enthält die neue Identität.
RunAs()-Authentifizierung
- Weitergabe der Caller-Identität (Standardverhalten)
- Delegierung an die RunAs-Identität, die Sie mit der RunAs-Spezifikation angeben können
Nachdem der Server den ursprünglichen Benutzer authentifiziert hat, authentifiziert der Server den RunAs-Benutzer. Falls diese Authentifizierung fehlschlägt, greift der Server auf die Weitergabe der Caller-Identität zurück.
Zur Verwendung der RunAs-Spezifikation müssen Sie im Implementierungsdeskriptor Ihrer Anwendung das Element run-as oder die Annotation @RunAs einfügen. Setzen Sie dieses Element auf die Sicherheitsrolle, an die Sie die Aufrufe delegieren möchten.
Weitere Informationen hierzu finden Sie unter RunAs-Authentifizierung in Liberty konfigurieren.
Proxy-Anmeldemodul
Die Proxy-Anmeldemodulklasse lädt das Anmeldemodul des Anwendungsservers und delegiert alle Operationen an die echte Anmeldemodulimplementierung. Die echte Anmeldemodulimplementierung ist als Delegierungsoption in der Optionskonfiguration angegeben. Das Proxy-Anmeldemodul wird benötigt, weil die Klassenlader für die gemeinsam genutzten Bibliotheken des Anwendungsserverprodukts für den Anwendungsklassenlader nicht sichtbar sind. Bei einer programmsteuerten Anwendungsanmeldung über die Methode Login() der Klasse LoginContext mit dem JAAS-Anmeldekontexteintrag "WSLogin" delegiert das Proxy-Anmeldemodul alle Arbeiten an den JAAS-Anmeldekontexteintrag "system.DEFAULT".
Anmeldung mit Zertifikat
Das Feature für die Anmeldung mit Zertifikat ermöglicht Ihnen, Webanforderungen wie Servlets zu authentifizieren, die clientseitige X.509-Zertifikate anstelle einer Benutzer-ID/Kennwort-Kombination verwenden.
Die Zertifikatsauthentifizierung funktioniert, indem ein Benutzer in der Benutzerregistry dem definierten Namen im Clientzertifikat einer Webanforderung zugeordnet wird. Die Vertrauensbeziehung wird hergestellt, indem das Clientzertifikat vom Server anerkannt wird. So muss beispielsweise der Unterzeichner des Clientzertifikats im Truststore des Servers vorhanden sein. Wenn dieser Mechanismus verwendet wird, müssen Benutzer kein Kennwort angeben, um als vertrauenswürdig anerkannt zu werden.
Weitere Informationen hierzu finden Sie unter Kommunikation mit Liberty schützen.
Anmeldemodul mit Hashtabelle
Suchen Sie die erforderlichen Attribute in der Benutzerregistry, fügen Sie die Attribute in eine Hashtabelle ein und fügen Sie dann die Hashtabelle in die Eigenschaft für den Status für gemeinsame Nutzung ein. Wenn die Identität in diesem Anmeldemodul gewechselt wird, müssen Sie die Hashtabelle der Eigenschaft für den Status für gemeinsame Nutzung hinzufügen. Wenn die Identität nicht gewechselt wird, der Code requiresLogin jedoch den Wert "true" hat, können Sie die Hashtabelle mit Attributen erstellen. Sie müssen in dieser Situation jedoch keine Hashtabelle erstellen, weil Liberty die Anmeldung für Sie durchführt. Möglicherweise empfiehlt es sich aber, eine Hashtabelle zu erstellen, um Attribute in besonderen Fällen zu erfassen. Wenn Sie beispielsweise eine eigene spezielle Benutzerregistry verwenden, kann die folgende Vorgehensweise eine einfache Lösung sein: UserRegistry-Implementierung erstellen, Hashtabelle verwenden und Benutzerattribute vom Server erfassen lassen.
Die folgenden Regeln definieren ausführlicher, wie eine Anmeldung über eine Hashtabelle durchgeführt wird. Sie müssen ein java.util.Hashtable-Objekt im Subjekt (öffentlicher oder privater Satz mit Berechtigungsnachweisen) oder im HashMap-Element "shared-state" verwenden. Die Klasse com.ibm.wsspi.security.token.AttributeNameConstants definiert die Schlüssel mit den Benutzerinformationen. Wenn das Hashtable-Objekt mit einem angepassten Anmeldemodul, das vor dem Anmeldemodul mit der Hashtabelle aufgelistet ist, in die Eigenschaft für den Status für gemeinsame Nutzung des Anmeldekontexts eingefügt wird, wird der Wert des Objekts java.util.Hashtable mit dem folgenden Schlüssel im hashMap-Element "shared-state" gesucht:
- Eigenschaft
- com.ibm.wsspi.security.cred.propertiesObject
- Referenz auf die Eigenschaft
- AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
- Erläuterung
- Dieser Schlüssel sucht das Hashtable-Objekt, das die erforderlichen Eigenschaften im Status für gemeinsame Nutzung des Anmeldekontexts enthält.
- Erwartetes Ergebnis
- Ein java.util.Hashtable-Objekt.
Wenn ein java.util.Hashtable-Objekt im Subjekt oder im gemeinsam genutzten Statusbereich gefunden wird, vergewissern Sie sich, dass die folgenden Eigenschaften in der Hashtabelle vorhanden sind:
- com.ibm.wsspi.security.cred.uniqueId
- Referenz auf die Eigenschaft
- AttributeNameConstants.WSCREDENTIAL_UNIQUEID
- Rückgabewert
- java.util.String
- Erläuterung
- Der Eigenschaftswert muss den Benutzer eindeutig bezeichnen. Für die Liberty-Standardimplementierung stellt diese Eigenschaft die Informationen dar, die in der Anwendungsberechtigungskonfiguration gespeichert sind. Die Informationen sind nach der Implementierung und der Durchführung der Zuordnung von Benutzern zu Rollen im Anwendungsimplementierungsdeskriptor enthalten. Sehen Sie sich die Beispiele für das erwartete Format an, wenn die Zuordnung von Benutzern zu Rollen durch Durchsuchen einer Benutzerregistry-Implementierung von Liberty durchgeführt wird.
- Beispiele für das erwartete Format
- Die Eigenschaft com.ibm.wsspi.security.cred.uniqueId ist erforderlich.
Tabelle 1. Formatbeispiele für uniqueId. Diese Tabelle enthält Beispiele für das erwartete Format. Benutzerregistry Formatwert (UniqueUserId) LDAP ldapRegistryRealm/cn=kevin,o=mycompany,c=use Basis basicRegistryRealm/kelvin
- com.ibm.wsspi.security.cred.securityName
- Referenz auf die Eigenschaft
- AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
- Rückgabewert
- java.util.String
- Erläuterung
- Diese Eigenschaft sucht nach dem securityName des Authentifizierungsbenutzers. Dieser Name wird im Allgemeinen als Anzeigename oder Kurzname bezeichnet. Liberty verwendet das Attribut securityName für die Anwendungsprogrammierschnittstellen getRemoteUser, getUserPrincipal, und getCallerPrincipal. Um die Kompatibilität mit der Standardimplementierung für den securityName-Wert zu gewährleisten, müssen Sie die Methode public String getUserSecurityName(String uniqueUserId) UserRegistry aufrufen.
- Beispiele für das erwartete Format
- Die Eigenschaft com.ibm.wsspi.security.cred.securityname ist erforderlich.
Tabelle 2. Formatbeispiele für securityName. Diese Tabelle enthält Beispiele für das erwartete Format. Benutzerregistry Formatwert (securityName) LDAP kevin Basis kevin
- com.ibm.wsspi.security.cred.group
- Referenz auf die Eigenschaft
- AttributeNameConstants. WSCREDENTIAL_GROUP
- Rückgabewert
- java.util.ArrayList
- Erläuterung
- Dieser Schlüssel sucht nach der Array-Liste der Gruppen, zu der dieser Benutzer gehört. Die Gruppen werden im Format Realmname/Benutzername angegeben. Das Format dieser Gruppen ist wichtig, da die Liberty-Berechtigungsengine die Gruppen für die Gruppe/Rolle-Zuordnungen im Implementierungsdeskriptor verwendet. Das Format muss mit dem von der Liberty-Standardimplementierung erwarteten Format übereinstimmen. Wenn Sie den Berechtigungsprovider eines anderen Anbieters verwenden, müssen Sie das Format verwenden, das von diesem Provider erwartet wird. Um die Kompatibilität mit der Standardimplementierung für den Wert, der die eindeutigen Gruppen-IDs festlegt, zu gewährleisten, rufen Sie die Methode public List getUniqueGroupIds(String uniqueUserId) UserRegistry auf.
- Beispiele für das erwartete Format
- Die Eigenschaft com.ibm.wsspi.security.cred.group ist erforderlich. Es ist nicht erforderlich, einen Benutzer Gruppen zuzuordnen.
Tabelle 3. Formatbeispiele für group. Diese Tabelle enthält Formatbeispiele für die Konfiguration der Zuordnung eingehender Identitäten. Benutzerregistry Formatwert (group) LDAP ldapRegistryRealm/cn=group1,o=Groups,c=US Basis basicRegistryRealm/group1
com.ibm.wsspi.security.cred.realm
- Referenz auf die Eigenschaft
- AttributeNameConstants. WSCREDENTIAL_REALM
- Rückgabewert
- java.util.String
- Erläuterung
- Mit dieser Schlüsseleigenschaft können Sie den Realmnamen der Benutzerregistry angeben, der im LTPA-Cookie gespeichert ist.
- Diese Schlüsseleigenschaft ist nicht erforderlich.
- com.ibm.wsspi.security.cred.cacheKey
- Referenz auf die Eigenschaft
- AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
- Rückgabewert
- java.lang.Object
- Erläuterung
- Diese Schlüsseleigenschaft kann ein Objekt angeben, das die eindeutigen Eigenschaften der Anmeldung darstellt. Dazu gehören die benutzerspezifischen Informationen und die dynamischen Benutzerattribute, die sich auf die Eindeutigkeit auswirken können. Wenn sich der Benutzer beispielsweise über Position A anmeldet, was sich möglicherweise auf die Zugangssteuerung auswirkt, muss der Cacheschlüssel Position A beinhalten, damit das empfangene Subjekt das richtige Subjekt für die aktuelle Position ist.
- Die Eigenschaft com.ibm.wsspi.security.cred.cacheKey ist nicht erforderlich. Wenn diese Eigenschaft nicht angegeben ist, wird der für WSCREDENTIAL_UNIQUEID angegebene Wert im Cache gesucht. Wenn diese Information im java.util.Hashtable-Objekt gefunden wird, erstellt Liberty ein Subjekt, das dem Subjekt gleicht, das den normalen Anmeldungsprozess durchläuft (zumindest für LTPA). Das neue Subjekt enthält ein WSCredential-Objekt und ein WSPrincipal-Objekt, das vollständig mit den im Hashtable-Objekt ermittelten Informationen gefüllt ist.