WebSphere Application Server unterstützt das Plug-in eigener JAAS-Anmeldemodule
(Java™ Authentication and Authorization Service) vor oder hinter dem Systemanmeldemodul von
WebSphere Application Server. Der Austausch
der Systemanmeldemodule von WebSphere Application Server, die zum Erstellen des Berechtigungsnachweises
WSCredential und des Principal "WSPrincipal" im Subject erforderlich sind, wird von WebSphere Application Server jedoch nicht unterstützt. Durch die Verwendung eines eigenen Anmeldemoduls können Sie zusätzliche Authentifizierungsentscheidungen treffen
oder dem Subject Informationen hinzufügen, um in einer Java EE-Anwendung (Java Platform,
Enterprise Edition) weitergehende, unter Umständen differenziertere Berechtigungsentscheidungen zu treffen.
Informationen zu diesem Vorgang
Mit WebSphere Application Server können Sie in einem Downstreamrozess Informationen
weitergegeben, die von einem angepassten Anmeldemodul zum Subject hinzugefügt
werden. Weitere Informationen hierzu finden Sie im Artikel Weitergabe von Sicherheitsattributen.Lesen Sie die Beschreibungen der Anmeldekonfigurationen im Artikel
Einstellungen für Einträge der Systemanmeldekonfiguration für Java Authentication and Authorization Service, um zu ermitteln, welche Anmeldekonfiguration
Sie für Ihre angepassten Anmeldemodule verwenden müssen.
WebSphere
Application Server unterstützt Änderungen der
Systemanmeldekonfiguration über die Administrationskonsole und die Verwendung des
Scripting-Dienstprogramms "wsadmin". Klicken Sie zum Konfigurieren der Systemanmeldung mit der Administrationskonsole auf
Sicherheit > Globale Sicherheit. Klicken Sie unter "Java Authentication
and Authorization Service" auf Systemanmeldungen.
Vorgehensweise
- Konfigurieren Sie eine Systemanmeldekonfiguration.
Verwenden Sie das folgende
Codebeispiel zum Definieren einer Systemanmeldekonfiguration mit dem Tool wsadmin. Das folgende
Jacl-Beispiel-Script fügt der Anmeldekonfiguration für das LTPA-Websystem ein
angepasstes Anmeldemodul hinzu.
Achtung: Die Zeilen
32, 33 und 34 im folgenden Codebeispiel wurden auf jeweils zwei Zeilen aufgeteilt.
1. #########################################
2. #
3. # security.xml öffnen
4. #
5. #########################################
6.
7.
8. set sec [$AdminConfig getid /Cell:hillside/Security:/]
9.
10.
11. #########################################
12. #
13. # systemLoginConfig suchen
14. #
15. #########################################
16.
17.
18. set slc [$AdminConfig showAttribute $sec systemLoginConfig]
19.
20. set entries [lindex [$AdminConfig showAttribute $slc entries] 0]
21.
22.
23. #########################################
24. #
25. # LTPA_WEB ein neues LoginModule hinzufügen
26. #
27. #########################################
28.
29. foreach entry $entries {
30. set alias [$AdminConfig showAttribute $entry alias]
31. if {$alias == "LTPA_WEB"} {
32. set newJAASLoginModuleId [$AdminConfig create JAASLoginModule
$entry {{moduleClassName
"com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy"}}]
33. set newPropertyId [$AdminConfig create Property $newJAASLoginModuleId
{{name delegate}{value "com.ABC.security.auth.CustomLoginModule"}}]
34. $AdminConfig modify $newJAASLoginModuleId
{{authenticationStrategy REQUIRED}}
35. break
36. }
37. }
38.
39.
40. #########################################
41. #
42. # Änderung speichern
43. #
44. #########################################
45.
46. $AdminConfig save 47.
Achtung: Das Scripting-Dienstprogramm wsadmin fügt ein neues Objekt am Ende der
Liste hinzu. Wenn Sie das eigene Anmeldemodul vor dem Anmeldemodul "AuthenLoginModule" einfügen möchten, löschen Sie das Anmeldemodul
"AuthenLoginModule", und erstellen Sie es nach dem Einfügen des eigenen Anmeldemoduls erneut.
Speichern Sie das Beispielscript in einer Datei
sample.jacl, und führen Sie
das Beispielscript mit dem folgenden Befehl aus:
wsadmin -f sample.jacl
- Entfernen Sie die aktuelle LTPA_WEB-Anmeldekonfiguration und alle Anmeldemodule.
Sie können das folgende
Jacl-Beispielscript verwenden, um die aktuelle Anmeldekonfiguration "LTPA_WEB" und
alle Anmeldemodule zu entfernen:
48. #########################################
49. #
50. # security.xml öffnen
51. #
52. #########################################
53.
54.
55. set sec [$AdminConfig getid /Cell:hillside/Security:/]
56.
57.
58. #########################################
59. #
60. # systemLoginConfig suchen
61. #
62. #########################################
63.
64.
65. set slc [$AdminConfig showAttribute $sec systemLoginConfig]
66.
67. set entries [lindex [$AdminConfig showAttribute $slc entries] 0]
68.
69.
70. #########################################
71. #
72. # Anmeldekonfiguration LTPA_WEB entfernen
73. #
74. #########################################
75.
76. foreach entry $entries {
77. set alias [$AdminConfig showAttribute $entry alias]
78. if {$alias == "LTPA_WEB"} {
79. $AdminConfig remove $entry
80. break
81. }
82. }
83.
84.
85. #########################################
86. #
87. # Änderung speichern
88. #
89. #########################################
90.
91. $AdminConfig save
- Stellen Sie die ursprüngliche LTPA_WEB-Konfiguration wieder her.
Mit dem folgenden Jacl-Beispielscript können Sie die ursprüngliche
Konfiguration LTPA_WEB wiederherstellen:
Achtung: Die Zeilen 122, 124
und 126 im folgenden Codebeispiel wurden nur zur besseren Lesbarkeit auf mehrere Zeilen aufgeteilt.
92. #########################################
93. #
94. # security.xml öffnen
95. #
96. #########################################
97.
98.
99. set sec [$AdminConfig getid /Cell:hillside/Security:/]
100.
101.
102. #########################################
103. #
104. # systemLoginConfig suchen
105. #
106. #########################################
107.
108.
109. set slc [$AdminConfig showAttribute $sec systemLoginConfig]
110.
111. set entries [lindex [$AdminConfig showAttribute $slc entries] 0]
112.
113.
114.
115. #########################################
116. #
117. # Anmeldekonfiguration LTPA_WEB wiederherstellen
118. #
119. #########################################
120.
121.
122. set newJAASConfigurationEntryId [$AdminConfig create
JAASConfigurationEntry $slc {{alias LTPA_WEB}}]
123.
124. set newJAASLoginModuleId [$AdminConfig create
JAASLoginModule $newJAASConfigurationEntryId
{{moduleClassName
"com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy"}}]
125.
126. set newPropertyId [$AdminConfig create Property
$newJAASLoginModuleId {{name delegate}{value "com.ibm.ws.security.web.AuthenLoginModule"}}]
127.
128. $AdminConfig modify $newJAASLoginModuleId
{{authenticationStrategy REQUIRED}}
129.
130.
131. #########################################
132. #
133. # Änderung speichern
134. #
135. #########################################
136.
137. $AdminConfig save
- Lassen Sie den Callback-Array vom Modul "ltpaLoginModule" in der Methode "login" initialisieren.
Die Anmeldemodule "ltpaLoginModule" und "AuthenLoginModule" von WebSphere
Application Server verwenden den Status für gemeinsame Benutzung (shared), um
Statusinformationen so zu speichern, dass angepasste Anmeldemodule die Informationen ändern
können. Das Anmeldemodul "ltpaLoginModule" initialisiert den Callback-Array in der Methode "login"
mit dem folgenden Code. Das Callback-Array wird vom Anmeldemodul "ltpaLoginModule" nur erstellt,
wenn im Bereich für gemeinsamen Status kein Array
definiert ist. Der Code für die Fehlerbehandlung wurde zur besseren Übersichtlichkeit aus dem folgenden Codebeispiel entfernt. Wenn Sie ein eigenes Anmeldemodul
vor dem Anmeldemodul "ltpaLoginModule" einfügen, kann das eigene
Anmeldemodul demselben Stil folgen, um den Callback im Status für gemeinsame Benutzung zu speichern.
Achtung: Im folgenden Codebeispiel sind mehrere Codezeilen
zur besseren Lesbarkeit auf mehrere Zeilen aufgeteilt.
138. Callback callbacks[] = null;
139. if (!sharedState.containsKey(
com.ibm.wsspi.security.auth.callback.Constants. CALLBACK_KEY)) {
140. callbacks = new Callback[3];
141. callbacks[0] = new NameCallback("Username: ");
142. callbacks[1] = new PasswordCallback("Password: ", false);
143. callbacks[2] = new com.ibm.websphere.security.auth.callback.
WSCredTokenCallbackImpl( "Credential Token: ");
144. try {
145. callbackHandler.handle(callbacks);
146. } catch (java.io.IOException e) {
147. . . .
148. } catch (UnsupportedCallbackException uce) {
149. . . .
150. }
151. sharedState.put( com.ibm.wsspi.security.auth.callback.
Constants.CALLBACK_KEY, callbacks);
152. } else {
153. callbacks = (Callback []) sharedState.get
( com.ibm.wsspi.security.auth.callback.Constants.CALLBACK_KEY);
154. }
- Lassen Sie den Callback-Array vom Modul "AuthenLoginModule" initialisieren.
Die Anmeldemodule "ltpaLoginModule" und "AuthenLoginModule" generieren beide
ein WSPrincipal- und ein WSCredential-Objekt für die Darstellung der authentifizierten Benutzer-ID und der
Sicherheitsberechtigungen. Die WSPrincipal- und WSCredential-Objekte werden ebenfalls in einem Status für gemeinsame Benutzung gespeichert. Eine JAAS-Anmeldung verwendet ein 2-PC-Protokoll (Two-Phase Commit, zweiphasige Festschreibung).
Zuerst werden die Anmeldemethoden in den Anmeldemodulen aufgerufen, die in der Anmeldekonfiguration
konfiguriert sind. Danach werden die zugehörigen COMMIT-Methoden aufgerufen. Ein eigenes
Anmeldemodul, das hinter den Anmeldemodulen "ltpaLoginModule" und "AuthenLoginModule" eingefügt wird, kann die
WSPrincipal- und WSCredential-Objekte ändern, bevor diese Objekte festgeschrieben werden.
Die WSCredential- und WSPrincipal-Objekte müssen nach Abschluss der Anmeldung im Subject vorhanden sein. Wenn diese Objekte nicht im Subject vorhanden sind,
weist der Laufzeitcode von WebSphere Application
Server das Subject zurück, um Sicherheitsentscheidungen zu treffen.
AuthenLoginModule verwendet den folgenden Code für die Initialisierung des
Callback-Array:
Achtung: Im folgenden Codebeispiel sind mehrere Codezeilen
zur besseren Lesbarkeit auf mehrere Zeilen aufgeteilt.
155. Callback callbacks[] = null;
156. if (!sharedState.containsKey( com.ibm.wsspi.security.auth.
callback.Constants.CALLBACK_KEY)) {
157. callbacks = new Callback[6];
158. callbacks[0] = new NameCallback("Username: ");
159. callbacks[1] = new PasswordCallback("Password: ", false);
160. callbacks[2] = new com.ibm.websphere.security.auth.callback.
WSCredTokenCallbackImpl( "Credential Token: ");
161. callbacks[3] = new com.ibm.wsspi.security.auth.callback.
WSServletRequestCallback ("HttpServletRequest: ");
162. callbacks[4] = new com.ibm.wsspi.security.auth.callback.
WSServletResponseCallback( "HttpServletResponse: ");
163. callbacks[5] = new com.ibm.wsspi.security.auth.callback.
WSAppContextCallback( "ApplicationContextCallback: ");
164. try {
165. callbackHandler.handle(callbacks);
166. } catch (java.io.IOException e) {
167. . . .
168. } catch (UnsupportedCallbackException uce {
169. . . .
170. }
171. sharedState.put( com.ibm.wsspi.security.auth.callback.
Constants.CALLBACK_KEY, callbacks);
172. } else {
173. callbacks = (Callback []) sharedState.get(com.ibm.wsspi.security.
auth.callback.Constants.CALLBACK_KEY);
174. }
- Rufen Sie den Anwendungskontext ab. Es werden drei weitere Objekte, die Callback-Informationen für die Anmeldung enthalten,
vom Web-Container an das Anmeldemodul "AuthenLoginModule" übergeben: ein Objekt
"java.util.Map", ein Objekt "HttpServletRequest" und ein Objekt "HttpServletResponse".
Diese Objekte stellen den Kontext der Webanwendung dar.
Sie können den Anwendungskontext, das Objekt "java.util.Map", mit der Methode "getContext" im Objekt
"WSAppContextCallback" aufrufen. Das Objekt "java.util.Map" wird mit den folgenden
Implementierungsdeskriptorinformationen erstellt.
Achtung: Im folgenden Codebeispiel sind mehrere Codezeilen
zur besseren Lesbarkeit auf mehrere Zeilen aufgeteilt.
175. HashMap appContext = new HashMap(2);
176. appContext.put( com.ibm.wsspi.security.auth.callback.
Constants.WEB_APP_NAME,web_application_name);
177. appContext.put( com.ibm.wsspi.security.auth.callback.Constants.
REDIRECT_URL,errorPage);
Nächste Schritte
Der Anwendungsname und das Objekt "HttpServletRequest" können
vom eigenen Anmeldemodul für die Ausführung von Zuordnungsfunktionen gelesen werden. Die Fehlerseite
der formularbasierten Anmeldung kann von einem eigenen Anmeldemodul geändert werden.
Neben dem JAAS-Framework unterstützt WebSphere Application Server auch
Trust Association Interceptor (TAI).
Mit einem eigenen Anmeldemodul können dem Caller-Subject
während der Authentifizierung weitere Arten von Berechtigungsnachweisen und Informationen hinzugefügt werden. Die Berechtigungsnachweise
von Fremdanbietern im Subject des aufrufenden Prozesses werden von WebSphere Application
Server im Rahmen des Sicherheitskontextes verwaltet. Das Caller-Subject
wird während der Verarbeitung der Anforderung an den aktiven Thread gebunden.
Wenn ein Web- oder EJB-Modul für die Verwendung der Calleridentität konfiguriert ist, wird
die Identität in einer EJB-Anforderung an den Downstream-Service weitergegeben. Der WSCredential-Berechtigungsnachweis
und alle Berechtigungsnachweise von Fremdanbietern im Caller-Subject werden nicht an die nachgeschalteten Server
weitergeben.
Stattdessen können einige Informationen auf der Basis der weitergegebenen Identität
auf dem Zielserver erneut generiert werden. Fügen Sie dem Subject des aufrufenden
Prozesses während der Authentifizierung Berechtigungsnachweise Dritter hinzu. Das Caller-Subject, das von der Methode WSSubject.getCallerSubject
zurückgegeben wird, ist schreibgeschützt und kann
somit nicht geändert werden.
Weitere Informationen zum WSSubject-Subject finden Sie im Artikel
Caller-Subject aus dem Thread für JAAS abrufen.