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 zuzugreifen, 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 Berechtigungsnachweisinformationen wird ein JAAS-Subjekt für diesen Benutzer erstellt. Das Subjekt enthält weitere Informationen zum Benutzer, wie z. B. den Gruppen, zu denen der Benutzer gehört, und den 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 kann oder nicht.
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 Caches, 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 Verarbeitung der Authentifizierung auf. Abhängig von den Berechtigungsnachweisdaten wird die Erstellung des Subjekts von mindestens einem Anmeldemodul verarbeitet. 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-Funktionalität verwendet wird, und speichert diese als relevante Berechtigungsnachweise im Subjekt. Sie können die im Subjekt gespeicherten Informationen auch anpassen, indem Sie die angepassten Anmeldemodule während dieses Prozesses einfügen.
- Benutzerregistrys
- Authentifizierungscache
- JAAS-Konfiguration
- JAAS-Anmeldemodule
- Callback-Handler
- Berechtigungsnachweisen und Token
- LTPA
SPNEGO
- Single Sign-on (SSO)
- Plug-in-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. Das Liberty-Profil unterstützt einfache konfigurationsbasierte Benutzerregistrys und leistungsfähigere LDAP-basierte Repositorys. Weitere Informationen finden Sie unter Benutzerregistry für das Liberty-Profil konfigurieren.
Mit der LDAP-Registry können Sie auch mehrere Repositorys zusammenfassen und die LDAP-Operationen in zwei oder mehr Registrys ausführen. Der Benutzer des Liberty-Profils kann das Feature für die Einbindung der LDAP-Registry entweder direkt in der Datei server.xml oder unter 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 erhalten. 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 dann ans aufrufende Programm zurückgesendet werden kann.
Authentifizierungscache
Da die Erstellung eines Subjekts relativ aufwendig ist, stellt das Liberty-Profil einen Authentifizierungscache bereit, in dem ein Subjekt nach erfolgreicher Authentifizierung eines Benutzers gespeichert werden kann. Die Standardverfallszeit für den Cache sind 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 Authentifizierungscaches 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 im Liberty-Profil konfigurieren.
JAAS-Konfiguration
- system.WEB_INBOUND
- Wird beim Zugriff auf Webressourcen wie Servlets und JSPs verwendet.
- WSLogin
- Wird von Anwendungen verwendet, wenn die programmgestützte Anmeldung verwendet wird.
- 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 verarbeitet die Authentifizierung, 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.
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 system.WEB_INBOUND-Konfiguration hinzufügen. Nähere Informationen hierzu finden Sie unter Angepasstes JAAS-Anmeldemodul für das Liberty-Profil konfigurieren.
JAAS-Anmeldemodule
Die JAAS-Konfiguration verwendet zur Erstellung des Subjekts einen Satz von Anmeldemodulen. Das Liberty-Profil 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, verarbeitet das Anmeldemodul userNameAndPassword die Authentifizierung. Wenn die Authentifizierungsdaten in Form eines SingleSignonToken bereitgestellt werden, verarbeitet nur das Anmeldemodul token die Authentifizierung.
- userNameAndPassword
- Verarbeitet die Authentifizierung, wenn ein Benutzername und ein Kennwort als Authentifizierungsdaten verwendet werden.
- certificate
- Verarbeitet die Authentifizierung, wenn die Authentifizierungsdaten für gegenseitiges SSL in Form eines X.509-Zertifikats bereitgestellt werden.
- token
- Verarbeitet die Authentifizierung, 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. Weitere 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 bereitstellen und in der erforderlichen Reihenfolge 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 verarbeiten 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 im Liberty-Profil 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
Das Liberty-Profil 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.
Berechtigungsnachweisen und Token
Wie im Abschnitt loginModule beschrieben, werden Berechtigungsnachweise im Rahmen des Subjekterstellungsprozesses erstellt. Das Liberty-Profil 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 LTPA-Schlüsseln (Lightweight Third Party Authentication), die während des ersten Serverstarts generiert werden, 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 zuzugreifen.
LTPA
LTPA ist für verteilte Umgebungen mit mehreren Anwendungsservern bestimmt. Im Liberty-Profil 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 später zu entschlüsseln und die Signatur 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 Profile-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. 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 in einem Server auf die Ressourcen in anderen Servern zugreifen können, sofern alle beteiligten Server dieselbe Benutzerregistry verwenden. LTPA erfordert, dass die konfigurierte Benutzerregistry ein zentral genutztes Repository sein muss, 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 empfangenden Servern nach der Berechtigungsprüfung zugänglich.
Jeder Server muss gültige Berechtigungsnachweise haben. Wenn die Berechtigungsnachweise ablaufen, muss der Server mit der Benutzerregistry kommunizieren, um sich zu authentifizieren. 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 Profile-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 Profile-Servers konfiguriert. Weitere Informationen zur LTPA-Unterstützung finden Sie unter LTPA im Liberty-Profil konfigurieren.

![[8.5.5.5 oder höher]](../ng_v8555.gif)
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 SPNEGO-Webauthentifizierung aktiviert ist und der Browser-Client auf eine geschützte Ressource auf dem Liberty-Server zugreift, ist SPNEGO für die Authentifizierung des Zugriffs auf die gesicherte Ressource verantwortlich, die in der HTTP-Anforderung angegeben ist. Der Browser-Client erstellt ein SPNEGO-Token und sendet es als Teil der HTTP-Anforderung an den Liberty Profile-Server. WebSphere Application Server ruft die Benutzeridentität vom SPNEGO-Token ab und prüft sie. Mit dieser Identität wird ein sicherer Kontext zwischen dem Benutzer und dem Anwendungsserver etabliert.
Weitere Informationen zu SPNEGO finden Sie unter SPNEGO. Weitere Informationen zur Konfiguration von SPNEGO auf dem Liberty Profile-Server finden Sie unter
SPNEGO-Authentifizierung im Liberty-Profil konfigurieren.
Single Sign-on (SSO)
SSO ermöglicht Benutzern, sich an einer Stelle (z. B. einem Server) anzumelden und auf Anwendungen in anderen Servern zuzugreifen, ohne erneut zur Anmeldung aufgefordert zu werden. Damit SSO funktioniert, müssen die LTPA-Schlüssel zwischen den verschiedenen Liberty Profile-Servern ausgetauscht werden, die Benutzerregistrys müssen dieselben sein, und das Token darf nicht abgelaufen sein. Für den Austausch der LTPA-Schlüssel können Sie die Datei ltpa.keys aus einem Server in 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 Profile-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 Berechtigungsnachweisinformationen 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 für das Liberty-Profil anpassen.
Plug-in-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 vom Liberty-Profil bereitgestellt werden. Nähere Informationen hierzu finden Sie unter Angepasstes JAAS-Anmeldemodul für das Liberty-Profil konfigurieren.
- Implementierung eines Trust-Association-Interceptors (TAI) für die Verarbeitung aller Authentifizierungen, die auf Webressourcen basieren. Weitere Informationen hierzu finden Sie unter Angepassten TAI für das Liberty-Profil entwickeln.
Weitere Einzelheiten 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 angibt, unterstützt das Liberty-Profil 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:Weitere 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 Verifizierungsstatus
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 Anmeldekontextes.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, wenn 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 Ausnahme 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 im Liberty-Profil konfigurieren.
Proxy-Anmeldemodul
Das Proxy-Anmeldemodul 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 programmgestützten 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 etabliert, 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 anerkannt zu werden.
Weitere Informationen hierzu finden Sie unter Kommunikation mit dem Liberty-Profil sichern.
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 das Liberty-Profil die Anmeldung für Sie durchführt. Sie können jedoch eine Hashtabelle 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 in der sharedState Hashmap 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 Anmeldekontextes 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 Anmeldekontextes 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ückgabe
- java.util.String
- Erläuterung
- Der Eigenschaftswert muss den Benutzer eindeutig bezeichnen. Für die Standardimplementierung des Liberty-Profils 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 zum erwarteten Format an, wenn die Zuordnung von Benutzern zu Rollen durch Durchsuchen einer Benutzerregistry-Implementierung des Liberty-Profils 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 erwartet 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ückgabe
- java.util.String
- Erläuterung
- Diese Eigenschaft sucht nach dem securityName des Authentifizierungsbenutzers. Dieser Name wird im Allgemeinen als Anzeigename oder Kurzname bezeichnet. Das Liberty-Profil 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 erwartet Format. Benutzerregistry Formatwert (securityName) LDAP kevin Basis kevin
- com.ibm.wsspi.security.cred.group
- Referenz auf die Eigenschaft
- AttributeNameConstants. WSCREDENTIAL_GROUP
- Rückgabe
- 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 Berechtigungsengine des Liberty-Profils die Gruppen für die Gruppen/Rolle-Zuordnungen im Implementierungsdeskriptor verwendet. Das Format muss mit dem von der Standardimplementierung des Liberty-Profils 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.cacheKey
- Referenz auf die Eigenschaft
- AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
- Rückgabe
- 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 das Liberty-Profil 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.