Programmgesteuerte Anmeldungen mit dem Java Authentication and Authorization Service entwickeln
Verwenden Sie diesen Artikel, um programmgesteuerte Anmeldungen mit dem Java Authentication and Authorization Service zu entwickeln.
Vorbereitende Schritte
JAAS ersetzt
die CORBA-APIs für programmgesteuerte Anmeldung.
- In den Informationen zum Entwickeln von Anwendungen, die CosNaming (CORBA-Naming-Schnittstelle) verwenden, können Sie sich detailliert darüber informieren, wie eine Umgebung konfiguriert werden muss, in der Thin-Client-Anwendungen auf ferne Ressourcen eines Servers zugreifen können.
- Wenn die Anwendung eine angepasste JAAS-Anmeldekonfiguration verwendet, stellen Sie sicher, dass diese korrekt definiert ist. Einzelheiten finden Sie im Artikel Programmgesteuerte Anmeldungen für JAAS (Java Authentication and Authorization Service) konfigurieren.
- Einige der JAAS-APIs sind durch Java™ 2-Sicherheitsberechtigungen geschützt. Wenn diese
APIs von Anwendungscode verwendet werden, müssen Sie sicherstellen, dass diese Berechtigungen
zur Datei was.policy der Anwendung hinzugefügt werden. Nähere Einzelheiten hierzu finden Sie in den folgenden Artikeln: Welche APIs durch Java 2-Sicherheitsberechtigungen geschützt sind, können Sie der Dokumentation zu den öffentlichen APIs von IBM Developer Kit, Java Technology Edition, JAAS und WebSphere Application Server im Artikel "Sicherheit: Lernmaterial" entnehmen.Einige der im Beispielcode dieser Dokumentation verwendeten APIs sind nachfolgend aufgelistet. Zu diesen APIs sind die jeweils erforderlichen Java 2-Sicherheitsberechtigungen angegeben.
- Die "javax.security.auth.login.LoginContext"-Konstruktoren werden durch das Objekt "createLoginContext" von "javax.security.auth.AuthPermission" geschützt.
- Die Methoden "javax.security.auth.Subject.doAs" und "com.ibm.websphere.security.auth.WSSubject.doAs" werden durch das Objekt "doAs" von javax.security.auth.AuthPermission geschützt.
- Die Methoden "javax.security.auth.Subject.doAsPrivileged" und "com.ibm.websphere.security.auth.WSSubject.doAsPrivileged" werden durch das Objekt "doAsPrivileged" von javax.security.auth.AuthPermission geschützt.
- Erweiterung des Modells von Java EE-Ressourcen (Java Platform, Enterprise Edition) für Berechtigungsprüfungen.
Durch ein Versehen beim Entwurf gibt die Methode "javax.security.auth.Subject.getSubject" in JAAS Version 1.0 nicht das Subjekt zurück, das dem aktiven Thread in einem "java.security.AccessController.doPrivileged"-Codeblock zugeordnet ist. Dies kann zu inkonsistentem Verhalten mit unerwünschten Auswirkungen führen. Die Klasse "com.ibm.websphere.security.auth.WSSubject" bietet eine Lösung für die Zuordnung des Subjekts zu einem aktiven Thread an. Die Klasse "com.ibm.websphere.security.auth.WSSubject" erweitert das JAAS-Modell um Java EE-Ressourcen für Berechtigungsprüfungen. Wenn das Subjekt innerhalb der Methode "com.ibm.websphere.security.auth.WSSubject.doAs" dem aktiven Thread zugeordnet wird oder der "com.ibm.websphere.security.auth.WSSubject.doAsPrivileged"-Codeblock Produktberechtigungsnachweise enthält, wird das Subjekt zur Berechtigungsprüfung für Java EE-Ressourcen verwendet.
- Benutzerschnittstellenunterstützung für das Definieren einer neuen JAAS-Anmeldekonfiguration. Sie können eine JAAS-Anmeldekonfiguration in der Administrationskonsole konfigurieren und in einem Konfigurationsrepository speichern. Anwendungen können neue JAAS-Anmeldekonfigurationen in der Administrationskonsole definieren. Die Daten werden dann im Konfigurationsrepository gespeichert. Allerdings unterstützt WebSphere Application Server immer noch das Format für die JAAS-Anmeldekonfiguration (einfache Textdatei) aus der JAAS-Standardimplementierung. Wenn eine Anmeldekonfiguration im Konfigurationsrepository und in einer unverschlüsselten Textdatei definiert ist, hat die Konfiguration im Repository Priorität. Im Folgenden sind die Vorteile der Definition von Anmeldekonfigurationen im Konfigurationsrepository aufgeführt:
- Unterstützung der Administrationskonsole für die Definition der JAAS-Anmeldekonfiguration
- Zentrale Verwaltung der Definition für die JAAS-Anmeldekonfiguration
- Verteilung der JAAS-Anmeldekonfiguration
- Anwendungsunterstützung für programmgesteuerte Authentifizierung.
WebSphere Application Server stellt JAAS-Anmeldekonfigurationen bereit, damit Anwendungen eine programmgesteuerte Authentifizierung bei der WebSphere-Sicherheitslaufzeit durchführen können. Diese Konfigurationen führen basierend auf den bereitgestellten Authentifizierungsdaten die Authentifizierung gemäß dem für WebSphere Application Server konfigurierten Authentifizierungsverfahren (SWAM oder LTPA) und unter Verwendung der definierten Benutzerregistry (LocalOS, LDAP, angepasste Registrys oder eingebundene Repositorys) und der Kerberos-Authentifizierung durch. Das mit diesen JAAS-Anmeldekonfigurationen authentifizierte Subjekt enthält den erforderlichen Principal sowie die erforderlichen Berechtigungsnachweise, die die WebSphere-Sicherheitslaufzeit zur Berechtigungsprüfung für Ressourcen benötigt, die mit der rollenbasierten Java EE-Sicherheit geschützt sind.
Anmerkung: SWAM ist in WebSphere Application Server Version 9.0 veraltet und wird in einem der künftigen Releases nicht mehr enthalten sein.WebSphere Application Server stellt die folgenden JAAS-Anmeldekonfigurationen bereit:- JAAS-Anmeldekonfiguration WSLogin. Dies ist eine generische JAAS-Anmeldekonfiguration, die auf einer Benutzer-ID und einem Kennwort oder einem an die Sicherheitslaufzeitumgebung von WebSphere Application Server übergebenen Token basiert und mit der unter anderem Java-Clients, Client-Container-Anwendungen, Servlets, JSP-Dateien und EJBs authentifiziert werden können. Diese Anmeldekonfiguration bietet jedoch keine Unterstützung für den CallbackHandler, der im Implementierungsdeskriptor des Client-Containers definiert ist.
- JAAS-Anmeldekonfiguration WSKRB5Login. Dies ist eine generische JAAS-Anmeldekonfiguration, die auf einer Benutzer-ID und einem Kennwort oder einem an die Sicherheitslaufzeitumgebung von WebSphere Application Server übergebenen Token basiert und mit der unter anderem Java-Clients, Client-Container-Anwendungen, Servlets, JSP-Dateien und EJB-Komponenten authentifiziert werden können. Diese Anmeldekonfiguration bietet jedoch keine Unterstützung für den CallbackHandler, der im Implementierungsdeskriptor des Client-Containers definiert ist.
- JAAS-Anmeldekonfiguration ClientContainer. Diese JAAS-Anmeldekonfiguration berücksichtigt den Callback-Handler, der im Implementierungsdeskriptor des Client-Containers angegeben wurde.
Das Anmeldemodul dieser Anmeldekonfiguration verwendet (falls vorhanden) den
CallbackHandler, der im Implementierungsdeskriptor des Client-Containers angegeben wurde, auch
wenn der Anwendungscode einen Callback-Handler im Anmeldekontext angibt.
Dies gilt für Client-Container-Anwendungen.
Ein Subjekt, das mit den zuvor genannten JAAS-Anmeldekonfigurationen authentifiziert wurde, enthält einen Principal com.ibm.websphere.security.auth.WSPrincipal und einen Berechtigungsnachweis com.ibm.websphere.security.cred.WSCredential. Wird das authentifizierte Subjekt mit "com.ibm.websphere.security.auth.WSSubject.doAs" oder einer anderen "doAs"-Methode übergeben, kann die Sicherheitslaufzeit des Produkts Berechtigungsprüfungen für die Java EE-Ressourcen basierend auf dem Subjekt "com.ibm.websphere.security.cred.WSCredential" durchführen.
- Benutzerdefinierte JAAS-Anmeldekonfigurationen.
Sie können andere JAAS-Anmeldekonfigurationen definieren, um eine programmgesteuerte Anmeldung durchzuführen, die ein angepasstes Subjekt im Client- oder Serverprozess erstellt. Es müssen bestimmte Berechtigungsnachweise und Principals im Subjekt enthalten sein, die die Sicherheitslaufzeitumgebung des Produkts benötigt, um Authentifizierungsinformationen vom Client über ein Protokoll zu senden oder um die Berechtigung auf dem Server zu bearbeiten. Di erforderlichen Berechtigungsnachweise werden von den bereitgestellten Anmeldemodulen generiert.
Das folgende Anmeldemodul wird für eine reine Java-Clientanmeldung benötigt:- com.ibm.ws.security.common.auth.module.WSLoginModuleImpl required;
- javax.security.auth.callback.NameCallback
- javax.security.auth.callback.PasswordCallback
Informationen zum Aktivieren der Weitergabe für einen reinen Java-Client finden Sie im entsprechenden Schritt im Artikel Sicherheitsattribute an Anwendungsserver weitergeben.Anmerkung: Damit die Weitergabe erfolgreich durchgeführt werden kann, müssen die Klassen, die dem Subjekt hinzugefügt werden, die Java-Serialisierung und -Entserialisierung unterstützen.Die folgenden Anmeldemodule werden für eine Serveranmeldung benötigt:- com.ibm.ws.security.server.lm.ltpaLoginModule required;
- com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule required;
- Namensvoraussetzungen für die programmgesteuerte Anmeldung bei einem
reinen Java-Client.
Wenn für die programmgesteuerte Anmeldung bei einem reinen Java-Client die Eigenschaft "com.ibm.CORBA.validateBasicAuth" auf true gesetzt ist, muss der Sicherheitscode wissen, wo sich der Sicherheitsserver befindet. Gewöhnlich reicht der Standardausgangskontext aus, wenn die Eigenschaft "java.naming.provider.url" als Systemeigenschaft oder in der Datei jndi.properties gesetzt ist. Es gibt jedoch auch Fälle, in denen es nicht empfehlenswert ist, dieselben "java.naming.provider.url"-Eigenschaften in einem systemweiten Geltungsbereich zu definieren. In solchen Fällen muss die Datei sas.client.props sicherheitsspezifische Boot-Informationen enthalten. Für die Suche nach dem Sicherheitsserver in einem reinen Java-Client gilt die folgende Suchhierarchie:
Vorgehensweise
Beispiel: Programmgesteuerte Anmeldung mit BasicAuth
Das folgende Beispiel veranschaulicht, wie Anwendungsprogramme eine programmgesteuerte Anmeldung mit BasicAuth durchführen können.
Programmgesteuerte Anmeldungen mit Kerberos-Token hinzufügen:
LoginContext lc = null;
try {
lc = new LoginContext("WSKRB5Login",
new WSCallbackHandlerImpl("userName", "password"));
} catch (LoginException le) {
System.out.println("Anmeldekontext kann nicht erstellt werden. " + le.getMessage());
// Code für Fehlerbearbeitung einfügen
} catch(SecurityException se) {
System.out.println("Cannot create LoginContext." + se.getMessage());
// Code für Fehlerbearbeitung einfügen
}
try {
lc.login();
} catch(LoginException le) {
System.out.println("Fails to create Subject. " + le.getMessage());
// Code für Fehlerbearbeitung einfügen
Wie im Beispiel gezeigt, wird der neue Anmeldekontext mit der Anmeldekonfiguration WSKRB5Login und dem Callback-Handler WSCallbackHandlerImpl initialisiert. Verwenden Sie die WSCallbackHandlerImpl-Instanz in einer serverseitigen Anwendung, wenn Sie keine Bedienerführung wünschen. Eine Instanz von WSCallbackHandlerImpl wird vom angegebenen angegebenen Benutzer (Benutzer-ID, Kennwort und Realminformationen) initialisiert. Die derzeitige Implementierungsklasse Krb5LoginModuleWrapperClient, die von WSKRB5Login angegeben wird, kann nur die Authentifizierungsdaten vom angegebenen Callback-Handler abrufen. Sie können mit einem Subject-Objekt zwar einen context erstellen, aber das Subject-Objekt wird von der aktuellen Krb5LoginModuleWrapperClient-Implementierung ignoriert.
Für reine Java-Anwendungsclients stellt das Produkt zwei weitere Callback-Handler-Implementierungen bereit: WSStdinCallbackHandlerImpl und WSGUICallbackHandlerImpl. Diese Implementierungen fordern Sie zur Eingabe der Benutzer-ID, des Kennworts und der Realminformationen in der Befehlszeile bzw. in Dialogfensteranzeigen auf. Je nach Anwendungsumgebung können Sie zwischen diesen beiden Callback-Handler-Implementierungen wählen. Sie können neue Callback-Handler entwickeln, wenn keine dieser Implementierungen den Anforderungen Ihrer Anwendung entspricht.
Es gibt noch weitere Callbacks, die mit WSKRB5Login, WSAuthMechOidCallbackImpl und WSCcacheCallBackHandlerImpl verwendet werden können. Mit WSAuthMechOidCallbackImpl können Sie die OID des Authentifizierungsverfahrens angeben. Der OID-Wert für das Kerberos-Authentifizierungsverfahren ist "1.2.840.113554.1.2.2". Mit WSCcacheCallBackHandlerImpl können Sie den Benutzernamen, den Namen des Kerberos-Realms und den vollständigen Pfad für den Kerberos-Berechtigungsnachweiscache angeben und festlegen, ob Sie die Standardposition für den Kerberos-Berechtigungsnachweiscache verwenden möchten. Wenn Sie sich für die Verwendung der Standardposition für den Kerberos-Berechtigungsnachweiscache entscheiden, wird der Kerberos-Cache für Berechtigungsnachweise ignoriert. Wenn Sie Kerberos für die Authentifizierung verwenden, müssen Sie die Datei sas.client.props aktualisieren.
Außerdem können Sie eigene Anmeldemodule erstellen, wenn die Standardimplementierung von WSLoginModuleImpl nicht alle Anforderungen erfüllt. Das Produkt bietet Dienstprogrammfunktionen, die von angepassten Anmeldemodulen verwendet werden können, die im nächsten Abschnitt beschrieben werden.
Sollte java.naming.provider.url weder als Systemeigenschaft noch in
der Datei jndi.properties definiert sein, ist kein
Standardausgangskontext (InitialContext) anwendbar, wenn der Produktserver
sich nicht an localhost:2809 befindet.
In diesem Fall müssen Sie vor der JAAS-Anmeldung mit dem Programm einen neuen
Kontext InitialContext erstellen. JAAS muss die Position
des Sicherheitsservers kennen, um die eingegebene Benutzer-ID und das zugehörige Kennwort
zu überprüfen, bevor ein die COMMIT-Operation durchgeführt wird. Wenn Sie wie weiter unten beschrieben
einen neuen Kontext InitialContext erstellen, enthält der Sicherheitscode die erforderlichen
Informationen, um damit den Sicherheitsserver und den Zielrealm zu ermitteln.
Sollte java.naming.provider.url weder als Systemeigenschaft noch in
der Datei jndi.properties definiert sein, ist kein
Standardausgangskontext (InitialContext) anwendbar, wenn der Produktserver
sich nicht an Servername:2809 befindet.
In diesem Fall müssen Sie vor der JAAS-Anmeldung mit dem Programm einen neuen
Kontext InitialContext erstellen. JAAS muss die Position
des Sicherheitsservers kennen, um die eingegebene Benutzer-ID und das zugehörige Kennwort
zu überprüfen, bevor ein die COMMIT-Operation durchgeführt wird. Wenn Sie wie weiter unten beschrieben
einen neuen Kontext InitialContext erstellen, enthält der Sicherheitscode die erforderlichen
Informationen, um damit den Sicherheitsserver und den Zielrealm zu ermitteln.
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
...
// Vor dem Anmelden Ausgangskontext erstellen und Standardsuche durchführen, damit Zielrealm
// und Bootstrap-Host/Port für das die Suche des Sicherheitsservers bestimmt werden können.
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
env.put(Context.PROVIDER_URL, "corbaloc:iiop:myhost.mycompany.com:2809");
Context initialContext = new InitialContext(env);
Object obj = initialContext.lookup("");
LoginContext lc = null;
try {
lc = new LoginContext("WSLogin",
new WSCallbackHandlerImpl("userName", "realm", "password"));
} catch (LoginException le) {
System.out.println("Anmeldekontext kann nicht erstellt werden. " + le.getMessage());
// Code für Fehlerbearbeitung
} catch(SecurityException se) {
System.out.printlin("Cannot create LoginContext." + se.getMessage();
// Fehlerbearbeitung einfügen
}
try {
lc.login();
} catch(LoginException le) {
System.out.printlin("Fehler beim Erstellen des Subjekts. " + le.getMessage());
// Code für Fehlerbearbeitung einfügen
}