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

Der Java Authentication and Authorization Service (JAAS) stellt die strategischen APIs für die Authentifizierung bereit.

[AIX Solaris HP-UX Linux Windows][IBM i]JAAS ersetzt die CORBA-APIs für programmgesteuerte Anmeldung.

WebSphere Application Server stellt einige Erweiterungen für JAAS bereit:
  • 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;
    Zusätzlich zur Verwendung dieses Anmeldemoduls muss der verwendete Callback-Handler in der Lage sein, die folgenden Callback-Klassen zu bearbeiten:
    • javax.security.auth.callback.NameCallback
    • javax.security.auth.callback.PasswordCallback
    Im Callback-Handler müssen ein Benutzername und ein Kennwort angegeben werden. Angepasste Klassen, die dem Subjekt auf der Clientseite hinzugefügt werden, müssen automatisch an den Server weitergeleitet werden, wenn die Weitergabe von Sicherheitsattributen aktiviert ist. Sie können das Kennwort auf null setzen, wenn Sie Identitätszusicherung ohne Kennwort verwenden möchten.
    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;
    Informationen zu den Callbacks, die für eine serverseitige Anmeldekonfiguration verwendet werden, finden Sie im Artikel Konfiguration für serverseitige JAAS-Authentifizierung und -Anmeldung anpassen.
  • 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:

Anmerkung: Setzen Sie com.ibm.CORBA.validateBasicAuth=false, wenn Sie eine Verbindung zu einem z/OS-Server herstellen möchten. Diese Funktion kann derzeit in verteilten Clients, die Verbindungen zu einem z/OS-Server herstellen möchten, nicht verwendet werden, weil der Sicherheitsserver mit dem Principal "UNAUTHENTICATED" gesucht wird, was auf z/OS-Systemen nicht unterstützt wird.

Vorgehensweise

  1. Suchen Sie in der Datei sas.client.props nach den folgenden Eigenschaften:
    com.ibm.CORBA.securityServerHost=myhost.mydomain
    com.ibm.CORBA.securityServerPort=mybootstrap port
    Wenn Sie diese Eigenschaften angegeben haben, ist gewährleistet, dass die Sicherheitsfunktion hier nach dem Sicherheitsserver sucht. Als Host und Port können Sie einen beliebigen gültigen WebSphere-Host und -Bootstrap-Port angeben. Der Sicherheitsserver ist in allen Serverprozessen enthalten. Deshalb ist es nicht von Bedeutung, welchen Host oder Port Sie auswählen. Wenn die genannten Eigenschaften angegeben sind, sucht die Sicherheitsinfrastruktur des Clientprozesses anhand der Informationen in der Datei sas.client.props nach dem Sicherheitsserver.
  2. Nehmen Sie den folgenden Code in Ihre Clientanwendung auf, um einen neuen InitialContext() zu erhalten:
    ...
       import java.util.Hashtable;
      	import javax.naming.Context;  
      	import javax.naming.InitialContext;
      	...
       
    // Die InitialContext- und die Standardsuche werden vor der
    // Anmeldung ausgeführt, um den Zielbereich und den Bootstrap-Host/Port
    // für die Suche nach dem Sicherheitsserver zu ermitteln.
       
       			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("");
    
    			// Code für programmgesteuerte Anmeldung hier einfügen.
    Führen Sie diesen Schritt vor einer programmgesteuerten Anmeldung aus. In diesem Code geben Sie einen URL-Provider für Ihren Namenskontext an, der jedoch auf einen gültigen WebSphere Application Server innerhalb der Zelle zeigen muss, der gegenüber Sie sich authentifizieren. Der Verweis auf eine Zelle ermöglicht, für Thread-spezifische programmgesteuerte Anmeldungen für verschiedene Zellen dieselbe systemweite Position für den Sicherheitsserver zu verwenden.
  3. Verwenden Sie die neue Standardmethode "InitialContext()" gemäß den für die Benennung geltenden Vorrangregeln, die im Beispiel zum Abrufen des Standardanfangskontextes beschrieben sind.

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.

[AIX Solaris HP-UX Linux Windows][z/OS]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.

[IBM i]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.

Achtung: Die erste Zeile, die mit env.put beginnt, wurde hier nur zur besseren Lesbarkeit auf zwei Zeilen aufgeteilt.
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
    }

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_pacs
Dateiname:tsec_pacs.html