WebSphere Application Server prend en charge l'ajout de modules dans un module de connexion JAAS
(Java™ Authentication and Authorization Service) personnalisé, avant ou après le module de connexion du système
de WebSphere Application Server. Toutefois, WebSphere Application Server ne prend pas en
charge le remplacement des modules de connexion du système WebSphere Application
Server qui permettent de créer le justificatif WSCredential et le principal WSPrincipal
dans le sujet. A l'aide d'un module de connexion personnalisé, vous pouvez soit prendre des décisions
d'authentification supplémentaires, soit ajouter des informations au sujet afin de prendre des décisions
d'authentification supplémentaires plus circonstanciées dans une application J2EE (Java Platform,
Enterprise Edition (Java EE).
Pourquoi et quand exécuter cette tâche
WebSphere Application Server permet de propager des informations en aval. Celles-ci sont ajoutées au sujet par un module de connexion personnalisé. Pour plus d'informations, voir
Propagation des attributs de sécurité. Pour déterminer la configuration de connexion à utiliser pour vous connecter aux modules
de connexion personnalisés, reportez-vous aux descriptions de configuration de connexion
dans l'article Paramètres de configuration de connexion système pour JAAS (Java Authentication and Authorization Service).
WebSphere Application Server
prend en charge la modification de la configuration de connexion système par le biais de la console d'administration et à l'aide de l'utilitaire de scripts wsadmin. Pour définir la configuration de connexion système à l'aide de la console
d'administration, cliquez sur Sécurité > Sécurité globale. Dans la section Service d'authentification et d'autorisation Java, cliquez sur Connexions système.
Procédure
- Configurez une configuration de connexion système.
Pour configurer une configuration de connexion système à l'aide de l'outil wsadmin, suivez l'exemple de code ci-dessous. Voici l'exemple de script JACL qui permet d'ajouter un module de connexion
personnalisé à la configuration de connexion système Web LPTA (Lightweight
Third-party Authentication).
Avertissement : Les lignes 32, 33 et 34 des exemples de code ci-dessous sont réparties sur deux lignes.
1. #########################################
2. #
3. # Ouverture de security.xml
4. #
5. #########################################
6.
7.
8. set sec [$AdminConfig getid /Cell:hillside/Security:/]
9.
10.
11. #########################################
12. #
13. # Recherche de systemLoginConfig
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. # Ajout d'un module LoginModule à LTPA_WEB
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. # sauvegarde de la modification
43. #
44. #########################################
45.
46. $AdminConfig save 47.
Avertissement : L'utilitaire de script wsadmin insère un nouvel objet à la
fin de la liste.
Pour insérer le module de connexion personnalisé avant le module de
connexion AuthenLoginModule, supprimez le module de connexion AuthenLoginModule et
créez-le à nouveau après avoir inséré le module de connexion personnalisé. Sauvegardez l'exemple de script
dans un fichier
sample.jacl, puis exécutez l'exemple de script à l'aide de la
commande suivante :
wsadmin -f sample.jacl
- Retirez la configuration de connexion LTPA_WEB en cours et tous les modules
de connexion.
Vous pouvez
utiliser l'exemple de script JACL suivant pour supprimer la configuration de connexion
LTPA_WEB en cours, ainsi que tous les modules de connexion :
48. #########################################
49. #
50. # Ouverture de security.xml
51. #
52. #########################################
53.
54.
55. set sec [$AdminConfig getid /Cell:hillside/Security:/]
56.
57.
58. #########################################
59. #
60. # Recherche de systemLoginConfig
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. # Suppression de la configuration de connexion LTPA_WEB
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. # sauvegarde de la modification
88. #
89. #########################################
90.
91. $AdminConfig save
- Restaurez la configuration LTPA_WEB d'origine.
Vous pouvez utiliser l'exemple de script JACL suivant pour restaurer
la configuration LTPA_WEB initiale :
Avertissement : Les lignes 122, 124 et 126 des exemples de code ci-dessous sont scindées en deux lignes ou plus à des fins
d'illustration.
92. #########################################
93. #
94. # Ouverture de security.xml
95. #
96. #########################################
97.
98.
99. set sec [$AdminConfig getid /Cell:hillside/Security:/]
100.
101.
102. #########################################
103. #
104. # Recherche de systemLoginConfig
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. # Recréation de la configuration de connexion LTPA_WEB
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. # sauvegarde de la modification
134. #
135. #########################################
136.
137. $AdminConfig save
- Faites en sorte que le module de connexion ltpaLoginModule initialise les appels
de la méthode de connexion.
Les modules de connexion ltpaLoginModule et AuthenLoginModule de
WebSphere Application Server utilisent l'état partagé pour sauvagarder les informations
d'état afin que les modules de connexion personnalisés puissent modifier les informations. Le module de connexion ltpaLoginModule initialise les appels de la méthode login en utilisant le
code ci-dessous. Les appels sont créés par le module de connexion ltpaLoginModule si
ceux-ci ne sont pas définis dans la zone d'état partagé. Dans l'exemple de code suivant,
le code de traitement des erreurs est supprimé pour rendre l'exemple plus concis. Si vous
insérez un module de connexion personnalisé avant le module de connexion ltpaLoginModule,
le module de connexion personnalisé peut suivre la méthode visant à sauvegarder le rappel
à l'état partagé.
Avertissement : Dans l'exemple de code
ci-dessous, plusieurs lignes sont scindées en deux à des fins d'illustration.
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 ("Jetondejustificatif: ");
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. }
- Faites en sorte que le module de connexion AuthenLoginModule initialise le tableau d'appel.
Les modules de connexion ltpaLoginModule et AuthenLoginModule
génèrent tous les deux un objet WSPrincipal et un objet WSCredential pour représenter
l'identité de l'utilisateur authentifié et les justificatifs de sécurité. Les objets WSPrincipal et WSCredential sont également sauvegardés à l'état partagé. Une connexion JAAS utilise un protocole de validation à deux phases.
Les méthodes de connexion des modules de connexion, définies dans la configuration de connexion, sont d'abord appelées. Les méthodes de validation sont appelées ensuite. Un module de connexion personnalisé, inséré après les modules ltpaLoginModule et
AuthenLoginModule, peut modifier les objets WSPrincipal et WSCredential avant leur
validation. Une fois la connexion établie, les objets WSCredential et WSPrincipal doivent être définis dans le sujet. Si ce n'est pas le cas, le code d'exécution de WebSphere Application Server
rejette le sujet pour prendre des décisions de sécurité.
Le module AuthenLoginModule utilise le code suivant pour initialiser les
appels :
Avertissement : Dans l'exemple de code
ci-dessous, plusieurs lignes sont scindées en deux à des fins d'illustration.
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 ("Jetondejustificatif: ");
161. callbacks[3] = new com.ibm.wsspi.security.auth.callback.
WSServletRequestCallback ("DemandeServletHttp: ");
162. callbacks[4] = new com.ibm.wsspi.security.auth.callback.
WSServletResponseCallback ("RéponseServletHttp: ");
163. callbacks[5] = new com.ibm.wsspi.security.auth.callback.
WSAppContextCallback ("RappelContexteApplication: ");
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. }
- Obtenez le contexte d'application. Trois autres objets, qui contiennent les informations de rappel de
la connexion, sont transmis par le conteneur Web au module de connexion AuthenLoginModule :
un objet java.util.Map, un objet HttpServletRequest et un objet HttpServletResponse. Ces objets représentent le contexte de l'application
Web.
Vous pouvez extraire le contexte de l'application (objet
java.util.Map) en appelant la méthode getContext sur l'objet
WSAppContextCallback. L'objet java.util.Map est créé avec les informations de
descripteur de déploiement ci-après.
Avertissement : Dans l'exemple de code
ci-dessous, plusieurs lignes sont scindées en deux à des fins d'illustration.
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);
Que faire ensuite
Le nom de l'application et l'objet HttpServletRequest
peuvent être lus par le module de connexion personnalisé pour exécuter des opérations de
mappage.
La page d'erreur de la connexion par formulaire peut être modifiée par un module
de connexion personnalisé. Outre la structure JAAS, WebSphere Application Server prend en
charge l'interface TAI (Trust Association Interface).
D'autres types de
justificatifs et d'informations peuvent être ajoutés au sujet de l'appelant lors du
processus d'authentification exécuté à l'aide d'un module de connexion personnalisé.
Les justificatifs tiers dans le sujet de l'appelant sont gérés par
WebSphere Application Server comme faisant partie du contexte de sécurité. Le sujet de
l'appelant est lié à l'unité d'exécution active pendant le traitement de la requête. Lorsqu'un module Web ou EJB (Enterprise JavaBeans) est configuré pour utiliser l'identité de l'appelant, l'identité de l'utilisateur est propagée au service en aval dans une
requête d'EJB. Le justificatif WSCredential et tout autre justificatif tiers dans le
sujet de l'appelant ne sont pas propagés en aval. En revanche, un certain nombre d'informations peuvent être générées à nouveau sur le serveur cible sur la base de l'identité propagée. Ajoutez des justificatifs tiers au sujet de l'appelant au cours de la phase d'authentification. Le sujet de l'appelant, renvoyé par la méthode WSSubject.getCallerSubject, est en
lecture seule et ne peut pas être modifié. Pour plus d'informations sur le sujet WSSubject, voir Extraction du sujet de l'appelant de l'unité d'exécution pour JAAS.