Authentifizierung

Benutzerregistrys

Bei der Validierung der Authentifizierungsdaten eines Benutzers rufen die Anmeldemodule die konfigurierte Benutzerregistry auf, um die Benutzerinformationen zu validieren. Liberty unterstützt sowohl eine einfache konfigurationsbasierte Benutzerregistry als auch eine leistungsfähigere LDAP-basierte Registry. 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. Liberty -Benutzer können 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 kostenintensiv ist, stellt Liberty einen Authentifizierungscache zum Speichern eines Subjekts bereit, nachdem die Authentifizierung eines Benutzers erfolgreich war. 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

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. Siehe Angepasstes JAAS -Anmeldemodul für Libertykonfigurieren.

JAAS-Anmeldemodule

Die JAAS-Konfiguration verwendet zur Erstellung des Subjekts einen Satz von Anmeldemodulen. Liberty stellt eine Gruppe von Anmeldemodulen in jeder Anmeldekonfiguration 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.

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 Liberty -Berechtigung funktioniert, muss das Subjekt die Berechtigungsnachweise WSCredential, WSPrincipalund 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.

Weitere Informationen finden Sie unter Angepasste JAAS -Anmeldemodule für eine Systemanmeldekonfiguration entwickeln.

Berechtigungsnachweise und Token

Wie im Abschnitt loginModuleerwähnt, werden Berechtigungsnachweise im Rahmen des Subjekterstellungsprozesses erstellt. Liberty erstellt die Berechtigungsnachweise WSCredential, SingleSignonTokenund 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 Libertyunterstützt LTPA SSO und Sicherheit in einer verteilten Umgebung durch Verschlüsselung. 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 ohne Aufforderung auf Ressourcen in anderen Liberty -Servern in derselben Domäne zugreifen. 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 Protokoll LTPA verwendet Chiffrierschlüssel zum Verschlüsseln und Entschlüsseln von Benutzerdaten, die zwischen Servern ausgetauscht werden. 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 zeitabhängig. 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 kann nach der Berechtigungsprüfung der Zugriff auf die Ressourcen des empfangenden Servers erfolgen.

Jeder Server muss gültige Berechtigungsnachweise haben. Wenn die Berechtigungsnachweise verfallen, muss der Server für die 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 die gemeinsame Nutzung von Schlüsseln zwischen verschiedenen Liberty -Servern 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 der Startzeit 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 , indem es als Relying Party fungiert. 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.

Für weitere Informationen über OpenID, siehe OpenID. Informationen zur Konfiguration von OpenID auf einem Liberty -Server finden Sie unter OpenID -Relying-Party in Libertykonfigurieren.

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 auf einem Liberty -Server finden Sie unter OpenID Connect-Provider in Liberty konfigurieren.

SPNEGO

Mit Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) können sich Benutzer einmal am Microsoft-Domänencontroller anmelden und auf geschützte Anwendungen auf Liberty -Servern zugreifen, ohne erneut dazu aufgefordert zu werden.

Wenn die SPNEGO-Webauthentifizierung aktiviert ist und ein Browser-Client oder ein Nicht-Browser-Client auf eine geschützte Ressource auf dem Liberty-Server zugreift, authentifiziert SPNEGO den Zugriff auf die gesicherte Ressource in der HTTP -Anfrage. Ein Browser-Client erstellt ein SPNEGO-Token. Ein Nicht-Browser-Client erstellt ein Kerberos-Service-Ticket (Kerberos-Token). Der Client sendet den Token als Teil der HTTP -Anfrage an den Liberty-Server. Die E-Mail-Adresse WebSphere® Application Server validiert und ruft die Benutzeridentität vom SPNEGO- oder Kerberos -Token ab. 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 -Anfragen mit SPNEGO-Webauthentifizierung ". Weitere Informationen zum Konfigurieren von SPNEGO auf dem Liberty -Server finden Sie unter SPNEGO-Authentifizierung in Liberty konfigurieren.

Eingeschränkte Kerberos-Delegierung für SPNEGO

Das Feature Kerberos für eingeschränkte Delegierung stellt zwei APIs bereit, die verwendet werden, um SPNEGO-Ausgangstokens für Back-End-Services zu erstellen, die die SPNEGO-Authentifizierung unterstützen, z. B. .NET-Server und andere Liberty -Server.

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 in verschiedenen Liberty -Servern ausgetauscht werden, die Benutzerregistrys müssen identisch sein und das Token darf nicht abgelaufen 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 auf einem Liberty-Server authentifiziert wird, wird das SSO-Token, das während des Authentifizierungsprozesses für den Benutzer erstellt wird, 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 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 zum Konfigurieren von SAML-Web-Browser-SSO auf dem Liberty -Server finden Sie unter SAML 2.0 Web Browser Single Sign-on.

Modulare Authentifizierung

Weitere Informationen über das JAAS Login-Modul und TAI finden Sie unter Erweiterte Authentifizierung in WebSphere Application Server.

IDAssertion (Zusicherung der Identität)

Neben der Authentifizierung, bei der eine anfordernde Entität ihre Identität nachweisen muss, unterstützt Liberty auch die Zusicherung der Identität. 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.

RunAs()-Authentifizierung

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 finden Sie unter RunAs -Authentifizierung in Libertykonfigurieren.

Proxy-Anmeldemodul

Die Proxy-Anmeldemodulklasse lädt das Anmeldemodul des Anwendungsservers und delegiert alle Operationen an die echte Anmeldemodulimplementierung. Die echte Implementierung des Anmeldemoduls ist als delegierte Option 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 programmgesteuerten Anwendungsanmeldung, die die Methode Login() der Klasse LoginContext mit dem Anmeldekontexteintrag WSLogin JAAS verwendet, delegiert das Proxy-Anmeldemodul die gesamte Arbeit an den system.DEFAULT JAAS -Anmeldekontexteintrag. Weitere Informationen finden Sie unter Angepasstes JAAS -Anmeldemodul für den Liberty -Anwendungsclientcontainer konfigurieren.

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.

Siehe Kommunikation mit Liberty 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. In dieser Situation müssen Sie keine Hashtabelle erstellen, da Liberty die Anmeldung für Sie übernimmt. 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 nach dem Hashtable-Objekt, das die erforderlichen Eigenschaften im gemeinsam genutzten Status 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ückgabewerte

  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 durchgeführt wird, indem Sie eine Benutzerregistry-Implementierung von Libertysuchen.

  Erwartete Formatbeispiele

  Tabelle 1. Formatbeispiele für uniqueId. Diese Tabelle enthält Beispiele für erwartete Formate.

  Benutzerregistry	Formatwert (UniqueUserId)
  LDAP	ldapRegistryRealm/cn=kevin,o=mycompany,c=use
  Basic	basicRegistryRealm/kelvin

  Die Eigenschaft com.ibm.wsspi.security.cred.uniqueId ist erforderlich.

• com.ibm.wsspi.security.cred.securityName

  Referenz auf die Eigenschaft

  AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME

  Rückgabewerte

  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 (APIs) getRemoteUser, getUserPrincipalund getCallerPrincipal . Rufen Sie die Methode public String getUserSecurityName(String uniqueUserId) UserRegistry auf, um die Kompatibilität mit der Standardimplementierung für den Wert securityName sicherzustellen.

  Erwartete Formatbeispiele

  Tabelle 2. Formatbeispiele für securityName. Diese Tabelle enthält Beispiele für erwartete Formate.

  Benutzerregistry	Formatwert (securityName)
  LDAP	kevin
  Basic	kevin

  Die Eigenschaft com.ibm.wsspi.security.cred.securityname ist erforderlich.

• com.ibm.wsspi.security.cred.group

  Referenz auf die Eigenschaft

  AttributeNameConstants. WSCREDENTIAL_GROUP

  Rückgabewerte

  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, weil die Gruppen von der Liberty -Berechtigungsengine für Gruppen-Rollen-Zuordnungen im Implementierungsdeskriptor verwendet werden. Das bereitgestellte Format muss dem Format entsprechen, das von der Liberty -Standardimplementierung erwartet wird. Wenn Sie den Berechtigungsprovider eines Fremdanbieters verwenden, müssen Sie das Format, das von diesem Provider erwartet wird, verwenden. 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.

  Erwartete Formatbeispiele

  Tabelle 3. Formatbeispiele für die Gruppe. 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
  Basic	basicRegistryRealm/group1

  Die Eigenschaft com.ibm.wsspi.security.cred.group ist erforderlich. Es ist nicht erforderlich, einen Benutzer Gruppen zuzuordnen.

• com.ibm.wsspi.security.cred.realm

  Referenz auf die Eigenschaft

  AttributeNameConstants. WSCREDENTIAL_REALM

  Rückgabewerte

  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ückgabewerte

  java.lang.Object

  Erläuterung

  Dieses Schlüsseleigenschaft kann ein Objekt angeben, das die eindeutigen Eigenschaften der Anmeldung beinhaltet. Dazu gehören die benutzerspezifischen Daten und die dynamischen Benutzerattribute, die die Eindeutigkeit beeinträchtigen 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, ist die Cachesuche der für WSCREDENTIAL_UNIQUEID angegebene Wert. Wenn diese Informationen im java.util.Hashtable -Objekt gefunden werden, erstellt Liberty ein Subject-Objekt, das dem Subject-Objekt gleicht, das den normalen Anmeldeprozess 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.