Programmgesteuerte Anmeldung für JAAS

Die programmgesteuerte Anmeldung ist eine Art der formularbasierten Anmeldung, die für die Authentifizierung sitespezifische Anmeldeformulare unterstützt, die der Darstellung der Anwendung entsprechen.

Wenn Enterprise-Bean-Clientanwendungen den Benutzer auffordern, Informationen zur Identifizierung anzugeben, muss der Autor der Anwendung diese Informationen erfassen und den Benutzer authentifizieren. Man kann die Arbeit des Programmierers grob dahingehend klassifizieren, wo die tatsächliche Benutzerauthentifizierung stattfindet:

Benutzer von Webanwendungen können auf viele Arten nach Authentifizierungsdaten gefragt werden. Das Element <login-config> in der Implementierungsdeskriptordatei der Webanwendung definiert das Verfahren, das zur Erfassung dieser Informationen verwendet wird. Programmierer, die es vorziehen, Anmeldeprozeduren anzupassen anstatt vielseitig einsetzbare Einheiten, wie z. B. einen 401-Dialog in einem Browser, zu verwenden, können über eine formularbasierte Anmeldung ein anwendungsspezifisches HTML-Formular für die Erfassung von Anmeldeinformationen bereitstellen.

Eine Authentifizierung erfolgt nur, wenn die Verwaltungssicherheit aktiviert ist. Wenn Sie für Webanwendungen die formularbasierte Anmeldung verwenden möchten, müssen Sie im Implementierungsdeskriptor der jeweiligen Anwendung im Element <login-config> für den Tag "auth-method" den Wert FORM angeben.

Anwendungen können sitespezifische Anmeldeformulare bieten, indem sie den formularbasierten Anmeldetyp von WebSphere Application Server verwenden. Die Java™-EE-Spezifikation (Java Platform, Enterprise Edition) definiert die formularbasierte Anmeldung als eine der Authentifizierungsmethoden für Webanwendungen. WebSphere Application Server bietet ein Verfahren für formularbasierte Abmeldung.

Programmgesteuerte JAAS-Anmeldung (Java Authentication and Authorization Service)

JAAS (Java Authentication and Authorization Service) ist ein neues Feature in WebSphere Application Server. Dieses Feature wird auch von der Spezifikation Java EE 1.4 vorausgesetzt. JAAS ist eine Sammlung strategischer Anwendungsprogrammierschnittstellen für die Authentifizierung, die die programmgesteuerten Anmelde-APIS von CORBA ersetzen. WebSphere Application Server stellt einige Erweiterungen für JAAS bereit:

Bevor Sie die Entwicklung mit APIs für programmgesteuerte Anmeldung beginnen, bedenken Sie Folgendes:
  • Wenn Sie eine reine Java-Clientanwendung oder Client-Container-Anwendung haben, müssen Sie die Sicherheit des Client-ORB (Object Request Broker) vor einer JAAS-Anmeldung initialisieren. Führen Sie dazu den folgenden Code vor der JAAS-Anmeldung aus:
    ...
    import java.util.Hashtable;
    import javax.naming.Context;
    import javax.naming.InitialContext;
    ...
    // Führen Sie vor Anmeldung ein InitialContext und ein Standard-Lookup
    // durch, damit die ORB-Sicherheit aktiviert wird und der Bootstrap-Host/-Port
    // für das SecurityServer-Lookup bestimmt werden können. Wenn Sie
    // die Benutzer-ID und das Kennwort während der JAAS-Anmeldung nicht validieren
    // möchten, inaktivieren Sie die Eigenschaft "com.ibm.CORBA.validateBasicAuth"
    // in der Datei "sas.client.props".
    
    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("");
    [z/OS]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.
  • Bei einer reinen Java-Clientanwendung oder einer Client-Container-Anwendung müssen Sie sicherstellen, dass der Hostname und die Portnummer in den Bootstrapeigenschaften der JNDI-Zielressource (Java Naming and Directory Interface) korrekt angegeben sind. Nähere Einzelheiten hierzu finden Sie im Abschnitt Anwendungen entwickeln, die CosNaming (Schnittstelle "CORBA Naming") verwenden.
  • Wenn die Anwendung eine angepasste JAAS-Anmeldekonfiguration verwendet, stellen Sie sicher, dass diese korrekt definiert ist. Nähere Einzelheiten finden Sie im Abschnitt 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. Weitere Informationen finden Sie in den Artikeln Anwendungen für die Java-2-Sicherheit die Datei "was.policy" hinzufügen, Mit PolicyTool Richtliniendateien für die Java-2-Sicherheit verwenden und Datei "was.policy" für Java-2-Sicherheit konfigurieren. Weitere Einzelheiten dazu, welche APIs durch die Java-2-Sicherheitsberechtigungen geschützt sind, finden Sie in der Dokumentation zu den öffentlichen APIs von IBM® Developer Kit, Java Technology Edition, JAAS und WebSphere Application Server. Die folgende Liste enthält die APIs, die in dem in dieser Dokumentation beschriebenen Beispielcode verwendet werden.
    • Die Konstruktoren javax.security.auth.login.LoginContext werden geschützt durch javax.security.auth.AuthPermission "createLoginContext".
    • javax.security.auth.Subject.doAs und com.ibm.websphere.security.auth.WSSubject.doAs werden geschützt durch javax.security.auth.AuthPermission "doAs".
    • javax.security.auth.Subject.doAsPrivileged und com.ibm.websphere.security.auth.WSSubject.doAsPrivileged werden geschützt durch javax.security.auth.AuthPermission "doAsPrivileged".
  • com.ibm.websphere.security.auth.WSSubject: Aufgrund eines Designfehlers in JAAS Version 1.0 gibt javax.security.auth.Subject.getSubject das dem aktiven Thread zugeordnete Subjekt in einem Codeblock von java.security.AccessController.doPrivileged nicht zurück. Dies kann zu inkonsistentem Verhalten führen, das problematisch ist und unerwünschten Aufwand erfordert. Die API com.ibm.websphere.security.auth.WSSubject bietet eine Lösung für die Zuordnung des Subjekts zum aktiven Thread an. Die API com.ibm.websphere.security.auth.WSSubject erweitert das JAAS-Modell für Java-EE-Ressourcen um Berechtigungsprüfungen. Das Subjekt, das dem aktiven Thread im Codeblock com.ibm.websphere.security.auth.WSSubject.doAs oder com.ibm.websphere.security.auth.WSSubject.doAsPrivileged zugeordnet ist, wird für die Berechtigungsprüfungen für Java-EE-Ressourcen verwendet.
  • Unterstützung in der Administrationskonsole zum Definieren einer neuen JAAS-Anmeldekonfiguration: Sie können die JAAS-Anmeldekonfiguration in der Administrationskonsole konfigurieren und in der Konfigurations-API von WebSphere Application Server speichern. Anwendungen können neue JAAS-Anmeldekonfigurationen in der Administrationskonsole definieren. Die Daten werden in dem Konfigurationsrepository, das mit der Konfigurations-API von WebSphere Application Server definiert wird, persistent gespeichert. WebSphere Application Server unterstützt jedoch weiterhin das Standardkonfigurationsformat für JAAS-Anmeldungen (einfache Textdatei), das von der JAAS-Standardimplementierung bereitgestellt wird. Wenn Sie doppelte Anmeldekonfigurationen in der Konfigurations-API von WebSphere Application Server und in Form unverschlüsselter Dateien definieren, hat die Anmeldekonfiguration in der Konfigurations-API von WebSphere Application Server Vorrang. Das Definieren der Anmeldekonfiguration in der Konfigurations-API von WebSphere Application Server bringt folgende Vorteile:
    • Sie können die JAAS-Anmeldekonfiguration in der Administrationskonsole definieren.
    • Sie können die JAAS-Anmeldekonfiguration zentral verwalten.
    • Sie können die JAAS-Anmeldekonfiguration in einer Installation von WebSphere Application Server Network Deployment verteilen.
  • JAAS-Anmeldekonfigurationen für WebSphere Application Server: WebSphere Application Server stellt JAAS-Anmeldekonfigurationen bereit, damit Anwendungen eine programmgesteuerte Authentifizierung bei der Laufzeit der Sicherheit von WebSphere Application Server durchführen können. Diese JAAS-Anmeldekonfigurationen für WebSphere Application Server führen die Authentifizierung ausgehend von den bereitgestellten Authentifizierungsdaten gemäß dem konfigurierten Authentifizierungsverfahren (SWAM oder LTPA) und unter Verwendung der Benutzerregistry (Local OS, LDAP oder Angepasst) durch. Das mit diesen JAAS-Anmeldekonfigurationen authentifizierte Subjekt enthält den erforderlichen Principal sowie die erforderlichen Berechtigungsnachweise, die die Sicherheit von WebSphere Application Server zur Laufzeit verwenden kann, um Berechtigungsprüfungen für die geschützten rollenbasierten Java-EE-Ressourcen durchzuführen.
    Anmerkung: Beachten Sie jedoch, dass SWAM ab WebSphere Application Server Version 9.0 als veraltet gilt und in einem der künftigen Releases entfernt wird.
    WebSphere Application Server stellt die folgenden JAAS-Anmeldekonfigurationen bereit:
    • JAAS-Anmeldekonfiguration WSLogin: Eine generische JAAS-Anmeldekonfiguration, die von Java-Clients, Client-Container-Anwendungen, Servlets, JSP-Dateien, Enterprise-Beans usw. verwendet werden kann, um eine Authentifizierung auf der Basis einer Benutzer-ID und eines Kennworts oder auf der Basis eines Tokens durchzuführen, das zur Laufzeit an die Sicherheit von WebSphere Application Server übergeben wird. Diese Konfiguration bietet jedoch keine Unterstützung für den CallbackHandler, der im Implementierungsdeskriptor des Client-Containers definiert ist.
    • JAAS-Anmeldekonfiguration ClientContainer: Diese JAAS-Anmeldekonfiguration erkennt den im Implementierungsdeskriptor des Client-Containers angegebenen CallbackHandler. Das Anmeldemodul dieser Anmeldekonfiguration verwendet (falls vorhanden) den CallbackHandler, der im Implementierungsdeskriptor des Client-Containers angegeben wurde, auch wenn der Anwendungscode einen CallbackHandler im Anmeldekontext angibt. Dies gilt für Client-Container-Anwendungen.
    • Die Subjekte, die mit den zuvor genannten JAAS-Anmeldekonfigurationen authentifiziert wurden, enthalten einen Principal com.ibm.websphere.security.auth.WSPrincipal und einen Berechtigungsnachweis com.ibm.websphere.security.auth.WSCredential. Wenn das authentifizierte Subjekt an die Methode com.ibm.websphere.security.auth.WSSubject.doAs (oder an andere doAs-Methoden) weitergegeben wird, kann die Sicherheit von WebSphere Application Server zur Laufzeit auf der Basis des Berechtigungsnachweises com.ibm.websphere.security.auth.WSCredential des Subjekts Berechtigungsprüfungen für Java-EE-Ressourcen vornehmen.
  • Benutzerdefinierte JAAS-Anmeldekonfigurationen: Sie können eigene JAAS-Anmeldekonfigurationen definieren. Einzelheiten finden Sie im Artikel Programmgesteuerte Anmeldungen für JAAS (Java Authentication and Authorization Service) konfigurieren. Mit diesen Anmeldekonfigurationen können Sie eine programmgesteuerte Authentifizierung mit angepassten Authentifizierungsverfahren vornehmen. Allerdings werden mit diesen benutzerdefinierten JAAS-Anmeldekonfigurationen authentifizierte Subjekte von der Sicherheit von WebSphere Application Server zur Laufzeit unter Umständen nicht für Berechtigungsprüfungen verwendet, wenn sie nicht die erforderlichen Principals und Berechtigungsnachweise enthalten.

Ursache für eine Anmeldeausnahme bei einer JAAS-Anmeldung ermitteln

Wenn nach dem Ausführen der API LoginContext.login eine Ausnahme vom Typ LoginException angezeigt wird, können Sie die Ursache anhand der konfigurierten Benutzerregistry ermitteln. In den Anmeldemodulen sind die Registry-Ausnahmen in eine Ausnahme des Typs com.ibm.websphere.security.auth.WSLoginFailedException gepackt. Diese Ausnahme hat eine Methode getCause, mit der Sie die gepackte Ausnahme nach dem Absetzen des vorherigen Befehls extrahieren können.

Es ist nicht gewährleistet, dass eine Ausnahme vom Typ WSLoginFailedException angezeigt wird, aber die meisten von der Benutzerregistry generierten Ausnahmen sind hier aufgeführt. Das folgende Beispiel zeigt eine API LoginContext.login mit dem zugehörigen Catch-Block. Die Ausnahme WSLoginFailedException muss der Klasse com.ibm.websphere.security.auth.WSLoginFailedException zugewiesen sein, wenn Sie die API getCause ausführen möchten.

Das folgende Beispiel für determineCause kann für die Verarbeitung von Ausnahmen des Typs CustomUserRegistry verwendet werden.
try 
    {
         lc.login(); 
    } 
    catch (LoginException le)
    {
		// die Ausnahmen durchsuchen, wenn sie in der Laufzeit auftreten
		Throwable root_exception = determineCause(le);
	
		// Jetzt kann mit "root_exception" ein bestimmter Ausnahmetyp
 // verglichen werden, wenn z. B. eine CustomUserRegistry-Typ
	// implementiert wurde, wüssten Sie, wonach hier zu suchen ist
    }


/* Methode zum Durchsuchen von WSLoginFailedException, um die eigentliche Ausnahme zu finden */

    public Throwable determineCause(Throwable e) 
      {
								Throwable root_exception = e, temp_exception = null;

								// Schleife fortsetzen, bis keine eingebetteten Ausnahmen des Typs WSLoginFailedException
 // oder WSSecurityException mehr vorhanden sind 
         while (true) 
				{
												if (e instanceof com.ibm.websphere.security.auth.WSLoginFailedException)
						{
														temp_exception = ((com.ibm.websphere.security.auth.WSLoginFailedException)
														e).getCause();
						}
												else if (e instanceof com.ibm.websphere.security.WSSecurityException)
						{
														temp_exception = ((com.ibm.websphere.security.WSSecurityException)
														e).getCause();
						}
												else if (e instanceof javax.naming.NamingException)
																// eingebettete LDAP-Ausnahme suchen
								{
																				temp_exception = ((javax.naming.NamingException)e).getRootCause();
								}
												else if (e instanceof your_custom_exception_here)
						{
																// Sofern erforderlich, hier angepasste Verarbeitung durchführen
						}
						else
						{
																// Diese Ausnahme hat nicht den gesuchten Typ; Suche abbrechen
 // Aus Sicht von WebSphere Application Server ist dies die Ursache
																return root_exception;
						}
												if (temp_exception != null)
						{
																// Ausnahme gefunden; jetzt zurück und prüfen;
 // ob eine weitere Ausnahme darin eingebettet ist
																root_exception = temp_exception;
																e = temp_exception;
								continue;
						}
						else
						{
																// Die eigentliche Ausnahme für diesen Aufrufpfad ist
 // gefunden; sie muss irgendwann eintreten
																return root_exception;
						}
				}
		}

Ursache für eine Anmeldeausnahme bei einem Servletfilter ermitteln

Sie können die eigentliche Ausnahme auch mit einem Servletfilter nach der formularbasierten Anmeldung ermitteln. Diese Ausnahme empfiehlt sich, weil sie dem Benutzer zeigt, was passiert. Sie können die folgende API ausführen, um die eigentliche Ausnahme zu ermitteln:
Throwable t = com.ibm.websphere.security.auth.WSSubject.getRootLoginException();  
if (t != null)  	
         t = determineCause(t);

Sobald die Ausnahme ermittelt ist, können Sie sie mit dem oben beschriebenen Beispiel für determineCause ausführen, um die Ursache aus der nativen Registry zu erhalten.

Weitergabe der Ursache einer Anmeldeausnahme an reine Java-Clients aktivieren

Derzeit wird die eigentliche Ausnehme aus Sicherheitsgründen nicht an reine Clients weitergeleitet. In einer Trusted-Umgebung können Sie die eigentliche Ausnahme jedoch an einen reinen Client weiterleiten. Wenn Sie die Weitergabe der Ursache einer Anmeldeausnahme an einen reinen Client weitergeben möchten, klicken Sie in der Administrationskonsole von WebSphere Application Server auf Sicherheit > Globale Sicherheit > Angepasste Eigenschaften, und definieren Sie die folgende Eigenschaft:

com.ibm.websphere.security.registry.propagateExceptionsToClient=true

Programmgesteuerte Anmeldung ohne Bedienerführung

WebSphere Application Server stellt eine Implementierung der Schnittstelle javax.security.auth.callback.CallbackHandler ohne Bedienerführung mit dem Namen com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl bereit. Mit dieser Schnittstelle kann eine Anwendung die Authentifizierungsdaten im Push-Modus an die Instanz WebSphere-LoginModule übertragen, um die Authentifizierung durchzuführen. Diese Funktion ist hilfreich, wenn ein serverseitiger Anwendungscode eine Identität authentifiziert und diese Identität zum Aufruf von Downstream-Java-EE-Ressourcen verwenden möchte.
javax.security.auth.login.LoginContext lc = null;

try  { 
lc = new javax.security.auth.login.LoginContext("WSLogin",
new com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl("user", 
      "securityrealm", "securedpassword"));

// Erstellen eines LoginContext und Angeben einer CallbackHandler-Implementierung.
// Die CallbackHandler-Implementierung bestimmt die Erfassung der Authentifizierungsdaten.
// In diesem Fall werden die Authentifizierungsdaten per "push" an das vom
// LoginModule implementierte Authentifizierungsverfahren übergeben.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Ein LoginContext konnte nicht instanziert werden. Ausnahme: " 
+ e.getMessage());
e.printStackTrace();

// Die Berechtigung "createLoginContext" (javax.security.auth.AuthPermission) wurde der
// Anwendung möglicherweise nicht gewährt, oder die JAAS-Anmeldekonfiguration ist nicht definiert.
}

if (lc != null)
try  { 
lc.login();  // Anmeldung ausführen
javax.security.auth.Subject s = lc.getSubject();
// Authentifiziertes Subjekt abrufen

// Java-EE-Ressource mit dem authentifizierten Subjekt aufrufen
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try  { 
bankAccount.deposit(100.00);  // bankAccount ist eine geschützte EJB
} catch (Exception e)  {
System.out.println("FEHLER: Kein Zugriff auf die EJB-Ressource. Ausnahme: " 
+ e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Anmeldung mit folgender Ausnahme gescheitert: " + e.getMessage());
e.printStackTrace();

// Gescheiterte Anmeldung. Es kann Logik für erneute Anmeldung eingefügt werden.
}

Sie können den Callback-Handler "com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl" mit einem reinen Java-Client, einem Clientanwendungscontainer, einer Enterprise-Bean, einer JSP-Datei, einem Servlet oder einer anderen Java-EE-Ressource (Java 2 Platform, Enterprise Edition) verwenden.

Anmerkung: Der Callback-Handler WSCallbackHandlerImpl richtet sich danach, ob Sie die Sicherheit von WebSphere Application Server oder Web Services Security verwenden. Für die WAS-Sicherheit befindet sich der Handler in der Datei sas.jar und für Web Services Security in der Datei was-wssecurity.jar.

Programmgesteuerte Anmeldung mit Benutzerschnittstelle

WebSphere Application Server bietet auch eine Implementierung der Schnittstelle javax.security.auth.callback.CallbackHandler über die grafische Benutzerschnittstelle. Hierbei werden über den Anmeldedialog der grafischen Benutzerschnittstelle die Authentifizierungsdaten eines Benutzers erfasst. Der Callback-Handler com.ibm.websphere.security.auth.callback.WSGUICallbackHandlerImpl zeigt einen Anmeldedialog an, in der der Benutzer zur Eingabe von Authentifizierungsdaten aufgefordert wird.
[z/OS][AIX HP-UX Solaris]Anmerkung: Dieses Verhalten erfordert, dass ein X11-Server in der DISPLAY-Umgebung aufgerufen wird.
javax.security.auth.login.LoginContext lc = null;

try  { 
lc = new javax.security.auth.login.LoginContext("WSLogin",
new com.ibm.websphere.security.auth.callback.WSGUICallbackHandlerImpl());

// Erstellen eines LoginContext und Angeben einer CallbackHandler-Implementierung.
// Die CallbackHandler-Implementierung bestimmt die Erfassung der Authentifizierungsdaten.
// In diesem Fall erfolgt die Erfassung über die GUI-Aufforderung zur Anmeldung.
// Die Daten werden an das vom LoginModule implementierte Authentifizierungsverfahren übergeben.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Ein LoginContext konnte nicht instanziert werden. Ausnahme: " 
+ e.getMessage());
e.printStackTrace();

// Die Berechtigung "createLoginContext" (javax.security.auth.AuthPermission) wurde der
// Anwendung möglicherweise nicht gewährt, oder die JAAS-Anmeldekonfiguration ist nicht definiert.
}

if (lc != null)
try  { 
lc.login();  // Anmeldung ausführen
javax.security.auth.Subject s = lc.getSubject();
// Authentifiziertes Subjekt abrufen

// Java-EE-Ressourcen mit dem authentifizierten Subjekt aufrufen
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try  { 
bankAccount.deposit(100.00);  // bankAccount ist eine geschützte Enterprise-Bean
} catch (Exception e)  {
System.out.println("FEHLER: Kein Zugriff auf die EJB-Ressource. Ausnahme: " 
+ e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Anmeldung mit folgender Ausnahme gescheitert: " + e.getMessage());
e.printStackTrace();

// Gescheiterte Anmeldung. Es kann Logik für erneute Anmeldung eingefügt werden.
}
Achtung: Vermeiden Sie die Verwendung des Callback-Handlers com.ibm.websphere.security.auth.callback.WSGUICallbackHandlerImpl für serverseitige Ressourcen wie Enterprise-Beans, Servlets, JSP-Dateien usw. Die GUI-Anmeldeaufforderung blockiert den Server für die Benutzereingabe. Dieses Verhalten ist bei einem Serverprozess nicht angemessen.

WebSphere Application Server stellt auch eine Implementierung der Schnittstelle javax.security.auth.callback.CallbackHandler im Kerberos-Cache für Berechtigungsnachweise bereit. Der Callback-Handler ist com.ibm.websphere.security.auth.callback.WSCcacheCallBackHandlerImpl. Mit dieser Schnittstelle kann eine Anwendung die Authentifizierungsdaten im Push-Modus an das WebSphere-LoginModule übertragen, um die Authentifizierung durchzuführen.

Diese Funktionalität ist nur vorhanden, um die Authentifizierung des Anwendungscodes auf der Clientseite gegenüber WebSphere Application Server mithilfe des Kerberos-Cache für Berechtigungsnachweise zu ermöglichen.

Wenn die folgenden Optionen in der Datei wsjaas_client.conf enthalten sind, setzen Sie sie auf den Wert "false".

   useDefaultKeytab=false
   useDefaultCcache=false
   tryFirstPass=false
   useFirstPass=false
   forwardable=false
   renewable=false
   renewable=false
   noaddress=false

javax.security.auth.login.LoginContext lc = null;

String krb5Ccache = /etc/krb5/krb5cc_utle;

try  { 
lc = new javax.security.auth.login.LoginContext("WSKRB5Login",
new com.ibm.websphere.security.auth.callback.WSCcacheCallBackHandlerImpl(user, krb5Realm, krb5Ccache, false));
// Erstellen eines LoginContext und Angeben einer CallbackHandler-Implementierung.
// Die CallbackHandler-Implementierung bestimmt die Erfassung der Authentifizierungsdaten.
// In diesem Fall erfolgt die Erfassung über die Standardeingabeaufforderung.
// Die Daten werden an das vom LoginModule implementierte Authentifizierungsverfahren übergeben.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Ein LoginContext konnte nicht instanziert werden. Ausnahme: 
          " + e.getMessage());
e.printStackTrace();

// Die Berechtigung "createLoginContext" (javax.security.auth.AuthPermission) wurde der
// Anwendung möglicherweise nicht gewährt, oder die JAAS-Anmeldekonfiguration ist nicht definiert.
}

if (lc != null)
try  { 
lc.login();  // Anmeldung ausführen
javax.security.auth.Subject s = lc.getSubject();
// Authentifiziertes Subjekt abrufen

// Java-EE-Ressource mit dem authentifizierten Subjekt aufrufen
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try  { 
bankAccount.deposit(100.00);  
// bankAccount ist eine geschützte Enterprise-Bean
} catch (Exception e)  {
System.out.println("FEHLER: Kein Zugriff auf die EJB-Ressource. Ausnahme: " 
       + e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Anmeldung mit folgender Ausnahme gescheitert: " + e.getMessage());
e.printStackTrace();

// Gescheiterte Anmeldung. Es kann Logik für erneute Anmeldung eingefügt werden.
}

Anwendungsserver mit dem Standard-Kerberos-Cache für Berechtigungsnachweise

javax.security.auth.login.LoginContext lc = null;

try  { 
lc = new javax.security.auth.login.LoginContext("WSKRB5Login",
new com.ibm.websphere.security.auth.callback.WSCcacheCallBackHandlerImpl(user, krb5Realm, null, true));
// Erstellen eines LoginContext und Angeben einer CallbackHandler-Implementierung.
// Die CallbackHandler-Implementierung bestimmt die Erfassung der Authentifizierungsdaten.
// In diesem Fall erfolgt die Erfassung über die Standardeingabeaufforderung.
// Die Daten werden an das vom LoginModule implementierte Authentifizierungsverfahren übergeben.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Ein LoginContext konnte nicht instanziert werden. Ausnahme: 
          " + e.getMessage());
e.printStackTrace();

// Die Berechtigung "createLoginContext" (javax.security.auth.AuthPermission) wurde der
// Anwendung möglicherweise nicht gewährt, oder die JAAS-Anmeldekonfiguration ist nicht definiert.
}

if (lc != null)
try  { 
lc.login();  // Anmeldung ausführen
javax.security.auth.Subject s = lc.getSubject();
// Authentifiziertes Subjekt abrufen

// Java-EE-Ressource mit dem authentifizierten Subjekt aufrufen
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try  { 
bankAccount.deposit(100.00);  
// bankAccount ist eine geschützte Enterprise-Bean
} catch (Exception e)  {
System.out.println("FEHLER: Kein Zugriff auf die EJB-Ressource. Ausnahme: " 
       + e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Anmeldung mit folgender Ausnahme gescheitert: " + e.getMessage());
e.printStackTrace();

// Gescheiterte Anmeldung. Es kann Logik für erneute Anmeldung eingefügt werden.
}

Anwendungsserver mit dem in Windows nativen Kerberos-Cache für Berechtigungsnachweise Der Client muss sich am
Microsoft Domain Controller anmelden.

javax.security.auth.login.LoginContext lc = null;

try  { 
lc = new javax.security.auth.login.LoginContext("WSKRB5Login",
new com.ibm.websphere.security.auth.callback.WSCcacheCallBackHandlerImpl(null, null, null, true));
// Erstellen eines LoginContext und Angeben einer CallbackHandler-Implementierung.
// Die CallbackHandler-Implementierung bestimmt die Erfassung der Authentifizierungsdaten.
// In diesem Fall erfolgt die Erfassung über die Standardeingabeaufforderung.
// Die Daten werden an das vom LoginModule implementierte Authentifizierungsverfahren übergeben.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Ein LoginContext konnte nicht instanziert werden. Ausnahme: 
          " + e.getMessage());
e.printStackTrace();

// Die Berechtigung "createLoginContext" (javax.security.auth.AuthPermission) wurde der
// Anwendung möglicherweise nicht gewährt, oder die JAAS-Anmeldekonfiguration ist nicht definiert.
}

if (lc != null)
try  { 
lc.login();  // Anmeldung ausführen
javax.security.auth.Subject s = lc.getSubject();
// Authentifiziertes Subjekt abrufen

// Java-EE-Ressource mit dem authentifizierten Subjekt aufrufen
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try  { 
bankAccount.deposit(100.00);  
// bankAccount ist eine geschützte Enterprise-Bean
} catch (Exception e)  {
System.out.println("FEHLER: Kein Zugriff auf die EJB-Ressource. Ausnahme: " 
       + e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Anmeldung mit folgender Ausnahme gescheitert: " + e.getMessage());
e.printStackTrace();

// Gescheiterte Anmeldung. Es kann Logik für erneute Anmeldung eingefügt werden.
}

WSKRB5Login-Modul

JAAS-Anmeldekonfiguration WSKRB5Login: Eine generische JAAS-Anmeldekonfiguration, die von Java-Clients, Client-Container-Anwendungen, Servlets, JSP-Dateien oder Enterprise-Beans verwendet werden kann, um eine Authentifizierung durchzuführen, die auf einem Kennwort des Kerberos-Principalnamens oder einem Kerberos-Cache für Berechtigungsnachweise basiert. Dabei werden die entsprechenden Daten an die Sicherheitslaufzeit von WebSphere Application Server übergeben. Diese Konfiguration bietet jedoch keine Unterstützung für den CallbackHandler, der im Implementierungsdeskriptor des Client-Containers definiert ist.

Stellen Sie die von Ihnen erstellte Datei krb5.ini oder krb5.conf an eine Standardposition. Befindet sich eine der Dateien nicht an der Standardposition, müssen Sie die JVM-Systemeigenschaft "java.security.krb5.conf" auf den korrekten Pfad und den Namen der Kerberos-Konfigurationsdatei setzen.

Auf der Windows-Plattform ist die Standardposition "c:\winnt\krb5.ini".

Auf einer Linux-Plattform ist die Standardposition "/etc/krb5.conf".

Auf anderen Unix-Plattformen ist die Standardposition "/etc/krb5/krb5.conf".

Auf einer z/OS-Plattform ist die Standardposition "/etc/krb5/krb5.conf".

Kerberos-Konfigurationseinstellungen, der Name des Kerberos-KDC (Key Distribution Center) und die Realmeinstellungen werden in der Kerberos-Konfigurationsdatei oder in den Systemeigenschaftendateien "java.security.krb5.kdc" und "java.security.krb5.realm" angegeben.

Programmgesteuerte Anmeldung mit Stdin-Bedienerführung

WebSphere Application Server stellt auch eine Implementierung der Schnittstelle javax.security.auth.callback.CallbackHandler im Kerberos-Cache für Berechtigungsnachweise bereit. Der Callback-Handler com.ibm.websphere.security.auth.callback.WSStdinCallbackHandlerImpl erfragt und erfasst die Authentifizierungsdaten von einem Benutzer über die Standardeingabe.
javax.security.auth.login.LoginContext lc = null;

try  { 
lc = new javax.security.auth.login.LoginContext("WSLogin",
new com.ibm.websphere.security.auth.callback.WSStdinCallbackHandlerImpl());

// Erstellen eines LoginContext und Angeben einer CallbackHandler-Implementierung.
// Die CallbackHandler-Implementierung bestimmt die Erfassung der Authentifizierungsdaten.
// In diesem Fall erfolgt die Erfassung über die Standardeingabeaufforderung.
// Die Daten werden an das vom LoginModule implementierte Authentifizierungsverfahren übergeben.
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Ein LoginContext konnte nicht instanziert werden. Ausnahme: 
          " + e.getMessage());
e.printStackTrace();

// Die Berechtigung "createLoginContext" (javax.security.auth.AuthPermission) wurde der
// Anwendung möglicherweise nicht gewährt, oder die JAAS-Anmeldekonfiguration ist nicht definiert.
}

if (lc != null)
try  { 
lc.login();  // Anmeldung ausführen
javax.security.auth.Subject s = lc.getSubject();
// Authentifiziertes Subjekt abrufen

// Java-EE-Ressource mit dem authentifizierten Subjekt aufrufen
com.ibm.websphere.security.auth.WSSubject.doAs(s,
new java.security.PrivilegedAction() {
public Object run() {
try  { 
bankAccount.deposit(100.00);  
// bankAccount ist eine geschützte Enterprise-Bean
} catch (Exception e)  {
System.out.println("FEHLER: Kein Zugriff auf die EJB-Ressource. Ausnahme: " 
       + e.getMessage());
e.printStackTrace();
}
return null;
}
}
);
} catch (javax.security.auth.login.LoginException e) {
System.err.println("FEHLER: Anmeldung mit folgender Ausnahme gescheitert: " + e.getMessage());
e.printStackTrace();

// Gescheiterte Anmeldung. Es kann Logik für erneute Anmeldung eingefügt werden.
}
Achtung: Vermeiden Sie die Verwendung des Callback-Handlers com.ibm.websphere.security.auth.callback.WSStdinCallbackHandlerImpl für serverseitige Ressourcen wie Enterprise-Beans, Servlets, JSP-Dateien usw. Die Eingabe aus der Standardeingabe wird nicht an die Serverumgebung gesendet. Die meisten Server werden im Hintergrund ausgeführt und haben keine Konsole. Wenn der Server allerdings eine Konsole hat, blockiert die Standardeingabe den Server bei der Benutzereingabe. Dieses Verhalten ist bei einem Serverprozess nicht angemessen.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



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