Développement de modules de connexion personnalisés pour une configuration de connexion système pour JAAS
Pour WebSphere Application Server, il existe plusieurs points de plug-in JAAS Java™ Authentication and Authorization Service) pour la configuration des connexions système. WebSphere Application Server utilise les configurations des connexions système pour authentifier les demandes entrantes, les demandes sortantes et les connexions aux serveurs internes.
Pourquoi et quand exécuter cette tâche
- WEB_INBOUND
- RMI_OUTBOUND
- RMI_INBOUND
- DEFAULT
Procédure
- Authentifiez les demandes Web à l'aide de la configuration de connexion
WEB_INBOUND.
La configuration de connexion WEB_INBOUND authentifie les demandes Web.
Pour plus d'informations sur la configuration WEB_INBOUND, notamment sur les rappels associés, voir "RMI_INBOUND, WEB_INBOUND, DEFAULT" dans Paramètres de configuration de connexion système pour JAAS (Java Authentication and Authorization Service).
La figure 1 présente un exemple de configuration utilisant un intercepteur TAI (Trust Association Interceptor) qui crée un sujet avec toutes les informations initiales transmises à la configuration de connexion WEB_INBOUND. Si l'intercepteur TAI n'est pas configuré, la procédure d'authentification s'applique directement à la configuration de connexion système WEB_INBOUND, qui comprend tous les modules de connexion associés à la figure 1. La figure 1 indique les points de connexion disponibles dans les modules de connexion personnalisés et où les modules de connexion ltpaLoginModule et wsMapDefaultInboundLoginModule sont nécessaires.Figure 1. Configuration de connexion WEB_INBOUND - Gérez les demandes sortantes à l'aide de la configuration de connexion RMI_OUTBOUND.
La configuration de connexion RMI_OUTBOUND est un point de plug-in pour la gestion des demandes sortantes. WebSphere Application Server utilise ce point de connexion pour créer les informations sérialisées envoyées en aval en fonction du sujet d'appel transmis et des autres données du contexte de sécurité, telles que les jetons de propagation. Un module de connexion peut utiliser ce point de connexion pour changer l'identité. Pour plus d'informations, voir Configuration du mappage d'identités sortantes vers un domaine cible différent. La figure 2 indique où vous pouvez connecter les modules de connexion personnalisés et spécifie l'emplacement où le module de connexion wsMapCSIv2OutboundLoginModule est requis.
Figure 2. Configuration de connexion RMI_OUTBOUNDPour plus d'informations sur la configuration de connexion RMI_OUTBOUND, notamment ses rappels associés, voir "RMI_OUTBOUND" dans Paramètres de configuration de connexion système pour JAAS (Java Authentication and Authorization Service).
- Gérez l'authentification entrante pour les demandes de bean entreprise avec la configuration de connexion RMI_INBOUND.
La configuration de connexion RMI_INBOUND est un point de connexion qui gère l'authentification des communications entrantes pour les demandes de bean enterprise. WebSphere Application Server utilise ce point de connexion pour une connexion initiale ou une connexion par propagation. Pour plus d'informations sur ces deux types de connexion, voir Propagation des attributs de sécurité. Lors d'une connexion par propagation, ce point de connexion permet de désérialiser les informations envoyées par un serveur en amont. Un module de connexion personnalisé peut utiliser ce point de connexion pour changer l'identité, gérer les jetons personnalisés, ajouter des objets personnalisés au sujet, etc. Pour plus d'informations sur le changement d'identité à l'aide d'un objet Hashtable référencé à la figure 3, voir Configuration du mappage d'identités entrantes. La figure 3 indique les emplacements de connexion dans des modules de connexion personnalisés et spécifie que les modules de connexion ltpaLoginModule et wsMapDefaultInboundLoginModule sont nécessaires.
Figure 3. Configuration de connexion RMI_INBOUNDPour plus d'informations sur la configuration de connexion RMI_INBOUND, notamment sur ses rappels associés, voir "RMI_INBOUND, WEB_INBOUND, DEFAULT" dans Paramètres de configuration de connexion système pour JAAS (Java Authentication and Authorization Service).
- Gérez tous les autres types de demande d'authentification à l'aide de la configuration de connexion DEFAULT. Configuration de connexion DEFAULT
La configuration de connexion DEFAULT est un point de connexion qui gère tous les autres types de demande d'authentification, notamment les demandes d'administration SOAP et l'authentification interne de l'ID serveur. Les connexions par propagation ne sont généralement pas effectuées sur ce point de connexion.
Pour plus d'informations sur la configuration de connexionDEFAULT, notamment sur les rappels associés, voir "RMI_INBOUND, WEB_INBOUND, DEFAULT" dans Paramètres de configuration de connexion système pour JAAS (Java Authentication and Authorization Service).
- Développez la configuration de connexion pour savoir quand des informations spécifiques sont
présentes et comment utiliser ces informations. Ecriture d'un module de connexionLorsque vous écrivez un module de connexion qui est branché dans une connexion d'application WebSphere Application Server ou une configuration de connexion de système, lisez le modèle de programmation JAAS qui se trouve sur : http://java.sun.com/products/jaas. Le modèle de programmation JAAS fournit des informations de base sur JAAS. Néanmoins, lisez les sections suivantes avant d'écrire un module de connexion pour l'environnement WebSphere Application Server :
- Rappels utilisables
- Variables d'état partagées
- Connexion d'origine / connexion par propagation
- Exemple de module de connexion personnalisé
Rappels utilisables
Chaque configuration de connexion doit documenter les rappels reconnus par la configuration de connexion. Toutefois, les rappels ne sont pas toujours des données transmises. La configuration de connexion doit contenir une logique permettant de savoir quand des informations spécifiques sont présentes et comment les utiliser. Par exemple, si vous écrivez un module de connexion personnalisé capable de s'intégrer dans les quatre configurations de connexion système pré-configurées citées précédemment, trois ensembles de rappels peuvent être présentés pour authentifier une demande. D'autres rappels peuvent être définis pour d'autre raisons, par exemple la propagation ou la transmission d'autres informations à la configuration de connexion.
Les informations de connexion peuvent être présentées dans les combinaisons suivantes :- Nom utilisateur (NameCallback) et mot de passe (PasswordCallback)
- Ces informations forment une combinaison d'authentification type.
- Nom utilisateur uniquement (NameCallback)
- Ces informations sont utilisées pour la vérification d'identité, les connexions TAI (Trust Association Interceptor) et les connexions par certificat.
- Jeton (WSCredTokenCallbackImpl)
- Ces informations sont destinées à la validation de jeton LTPA (Lightweight Third Party Authentication).
- Liste de jetons de propagation (WSTokenHolderCallback)
- Ces informations sont utilisées pour une connexion par propagation.
Les trois premières combinaisons sont utilisées pour l'authentification typique. Toutefois, lorsque le rappel WSTokenHolderCallback est présent en plus de l'une des trois combinaisons d'informations, la connexion est dite connexion par propagation. Avec ce type de connexion, certains attributs de sécurité sont propagés vers ce serveur à partir d'un autre serveur. Les serveurs peuvent réutiliser ces attributs de sécurité si la validation des informations d'authentification aboutit. Dans certains cas, il est possible que le rappel WSTokenHolderCallback ne dispose pas de suffisamment d'attributs pour que la connexion soit complète. Vérifiez la méthode requiresLogin sur le rappel WSTokenHolderCallback pour déterminer si une nouvelle connexion est requise. Vous pouvez ignorer les informations renvoyées par la méthode requiresLogin, mais cela peut entraîner une duplication des informations. La liste suivante répertorie tous les rappels susceptibles d'être présents dans les configurations de connexion de système. Cette liste inclut le nom de rappel et une description de leurs responsabilités.- callbacks[0] = new javax.security.auth.callback.NameCallback("Username: ");
- Ce gestionnaire de rappels collecte le nom d'utilisateur pour la connexion. Le résultat peut être le nom d'utilisateur pour une connexion d'authentification de base (nom d'utilisateur et mot de passe) ou un nom d'utilisateur pour une connexion par vérification d'identité.
- callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password: ", false);
- Ce gestionnaire de rappels collecte le mot de passe pour la connexion.
- callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token:");
- Ce gestionnaire de rappels collecte le jeton LTPA (Lightweight Third Party Authentication) ou tout autre type de jeton pour la connexion. Ce gestionnaire de rappels est habituellement présent lorsque le nom d'utilisateur et le mot de passe sont absents.
- callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List:");
- Ce gestionnaire de rappels collecte la liste ArrayList des objets TokenHolder renvoyés à partir d'un appel de l'API WSOpaqueTokenHelper.createTokenHolderListFromOpaqueToken () en utilisant le jeton d'autorisation CSIv2 (Common Secure Interoperability Version 2) en entrée.
- callbacks[4] = new com.ibm.websphere.security.auth.callback.WSServletRequestCallback("HttpServletRequest:" );
- Ce gestionnaire de rappels collecte l'objet de demande de servlet HTTP, s'il est présent. Ce gestionnaire de rappels permet aux modules de connexion d'obtenir les informations de la demande HTTP à utiliser dans la connexion ; il n'est présenté qu'à partir de la configuration de connexion WEB_INBOUND.
- callbacks[5] = new com.ibm.websphere.security.auth.callback.WSServletResponseCallback("HttpServletResponse:");
- Ce gestionnaire de rappels collecte l'objet de réponse de servlet HTTP, s'il est présent. Ce gestionnaire de rappels permet aux modules de connexion d'insérer des informations dans la réponse HTTP suite à la connexion. Il peut par exemple s'agir de l'ajout du cookie SingleSignonCookie à la réponse. Ce gestionnaire de rappels n'est présenté qu'à partir de la configuration de connexion WEB_INBOUND.
- callbacks[6] = new com.ibm.websphere.security.auth.callback.WSAppContextCallback("ApplicationContextCallback:");
- Ce gestionnaire de rappels collecte le contexte d'application Web utilisé pendant la connexion. Ce gestionnaire d'appel est composé d'un objet HashMap contenant le nom de l'application et l'adresse Web de redirection, le cas échéant. Le gestionnaire de rappels n'est présenté qu'à partir de la configuration de connexion WEB_INBOUND.
- callbacks[7] = new WSRealmNameCallbackImpl("Realm Name:", default_realm);
- Ce gestionnaire de rappels collecte le nom de domaine pour les informations de connexion. Les informations sur le domaine ne sont pas toujours fournies. Si c'est le cas, assumez qu'il s'agit du domaine courant.
- callbacks[8] = new WSX509CertificateChainCallback("X509Certificate[]: ");
- Ce gestionnaire de rappels contient un certificat validé par SSL (Secure Sockets Layer) si la source de la connexion est un X509Certificate de l'authentification client SSL. Le module ltpaLoginModule appelle les mêmes fonctions de mappage que les versions antérieures à 6.1 de WebSphere Application Server. Toutefois, la transmission dans la connexion donne à un module de connexion personnalisé l'occasion de mapper le certificat d'une façon personnalisée. Il effectue ensuite une connexion Hashtable. Pour plus d'informations sur la connexion Hashtable, voir Configuration du mappage d'identités entrantes.
- Utilisez les variables d'état partagées pour partager des informations entre les modules de connexion pendant
la phase de connexion. Si vous souhaitez accéder aux objets créés par WebSphere Application Server pendant une connexion, voir les variables d'état partagé suivantes. Les variables sont définies dans les modules de connexion ltpaLoginModule, swamLoginModule et wsMapDefaultInboundLoginModule.
- Variable d'état partagé
- com.ibm.wsspi.security.auth.callback.Constants.WSPRINCIPAL_KEY
- Objectif
- Spécifie l'objet com.ibm.websphere.security.auth.WSPrincipal. Pour plus d'informations sur l'utilisation de l'API, voir la documentation de l'API de WebSphere Application Server. Cette variable d'état partagé est disponible en lecture seule. Ne définissez pas cette variable dans l'état partagé pour les modules de connexion personnalisés.
- Module de connexion dans lequel des variables sont définies
- ltpaLoginModule, swamLoginModule et wsMapDefaultInboundLoginModule
- Variable d'état partagé
- com.ibm.wsspi.security.auth.callback.Constants.WSCREDENTIAL_KEY
- Objectif
- Spécifie l'objet com.ibm.websphere.security.cred.WSCredential. Pour plus d'informations sur l'utilisation de l'API, voir la documentation de l'API de WebSphere Application Server. Cette variable d'état partagé est disponible en lecture seule. Ne définissez pas cette variable dans l'état partagé pour les modules de connexion personnalisés.
- Module de connexion dans lequel des variables sont définies
- wsMapDefaultInboundLoginModule
- Variable d'état partagé
- com.ibm.wsspi.security.auth.callback.Constants.WSAUTHZTOKEN_KEY
- Objectif
- Spécifie l'objet com.ibm.wsspi.security.token.AuthorizationToken par défaut. Les modules de connexion peuvent utiliser cet objet pour définir des attributs personnalisés ajoutés après le module de connexion wsMapDefaultInboundLoginModule. Les informations spécifiées ici sont propagées en aval et disponibles pour l'application. Pour plus d'informations sur l'utilisation de l'API, voir la documentation de l'API de WebSphere Application Server.
Connexion d'origine / connexion par propagation
Comme indiqué précédemment, certaines connexions sont considérées comme des connexions initiales pour les raisons suivantes :- Les informations d'authentification sont présentées pour la première fois à WebSphere Application Server.
- Les informations de connexion sont reçues d'un serveur qui ne propage pas les attributs de sécurité, ce qui fait que les informations doivent être regroupées à partir d'un registre d'utilisateurs.
Les autres connexions sont considérées comme des connexions par propagation lorsqu'un rappel WSTokenHolderCallback est présent et contient suffisamment d'informations à partir d'un serveur d'origine pour recréer tous les objets requis par le contexte d'exécution de WebSphere Application Server. Si ces informations ne sont pas suffisantes pour l'environnement d'exécution de WebSphere Application Server, les données que vous pouvez ajouter au sujet existent probablement à partir de la connexion précédente. Pour vérifier si l'objet est présent, vous pouvez accéder à l'objet ArrayList du rappel WSTokenHolderCallback et rechercher l'objet dans la liste en vérifiant chaque méthode TokenHolder getName. Cette recherche permet de déterminer si WebSphere Application Server désérialise l'objet personnalisé lors de cette connexion. Vérifiez le nom de classe renvoyé par la méthode getName à l'aide de la méthode STring startsWith car l'environnement d'exécution peut ajouter des informations supplémentaires à la fin du nom pour déterminer le sujet défini pour ajouter l'objet personnalisé après la désérialisation.
- Codez votre méthode login() pour
déterminer le moment où suffisamment d'informations sont présentes.
Le fragment de code suivant peut être utilisé dans votre méthode login() pour déterminer le moment où suffisamment d'informations sont présentes. Pour obtenir un autre exemple, voir Configuration du mappage d'identités entrantes.
// Conseil donné par WebSphere Application Server indiquant // qu'il n'y a pas suffisamment d'informations de propagation et qu'une // connexion est par conséquent requise pour en fournir suffisamment. Dans ce // cas, une connexion de table de hachage peut être utilisée. boolean requiresLogin = ((com.ibm.wsspi.security.auth.callback. WSTokenHolderCallback) callbacks[1]).requiresLogin(); if (requiresLogin) { // Vérifiez si l'objet existe dans la liste TokenHolder, dans le cas contraire, ajoutez-le. java.util.ArrayList authzTokenList = ((WSTokenHolderCallback) callbacks[6]). getTokenHolderList();boolean found = false; if (authzTokenList != null) { Iterator tokenListIterator = authzTokenList.iterator(); while (tokenListIterator.hasNext()) { com.ibm.wsspi.security.token.TokenHolder th = (com.ibm.wsspi.security.token. TokenHolder) tokenListIterator.next(); if (th != null && th.getName().startsWith("com.acme.myCustomClass")) { found=true; break; } } if (!found) { // Continuez et ajoutez l'objet personnalisé. } } } else { // Ce code indique que suffisamment d'informations de propagation sont présentes. // WebSphere Application Server ne requiert pas d'appels du registre d'utilisateurs // pour créer un sujet valide. Ce code peut être une instruction no-op dans votre module de connexion. }
Exemple de module de connexion personnalisé
Vous pouvez utiliser l'exemple suivant pour avoir une idée de la manière d'utiliser certains des rappels et des variables d'état partagées.
{ // Defines your login module variables com.ibm.wsspi.security.token.AuthenticationToken customAuthzToken = null; com.ibm.wsspi.security.token.AuthenticationToken defaultAuthzToken = null; com.ibm.websphere.security.cred.WSCredential credential = null; com.ibm.websphere.security.auth.WSPrincipal principal = null; private javax.security.auth.Subject _subject; private javax.security.auth.callback.CallbackHandler _callbackHandler; private java.util.Map _sharedState; private java.util.Map _options; public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options) { _subject = subject; _callbackHandler = callbackHandler; _sharedState = sharedState; _options = options; } public boolean login() throws LoginException { boolean succeeded = true; // Gets the CALLBACK information javax.security.auth.callback.Callback callbacks[] = new javax.security. auth.callback.Callback[7]; callbacks[0] = new javax.security.auth.callback.NameCallback( "Username: "); callbacks[1] = new javax.security.auth.callback.PasswordCallback( "Password: ", false); callbacks[2] = new com.ibm.websphere.security.auth.callback. WSCredTokenCallbackImpl ("Credential Token: "); callbacks[3] = new com.ibm.wsspi.security.auth.callback. WSServletRequestCallback ("HttpServletRequest: "); callbacks[4] = new com.ibm.wsspi.security.auth.callback. WSServletResponseCallback ("HttpServletResponse: "); callbacks[5] = new com.ibm.wsspi.security.auth.callback. WSAppContextCallback ("ApplicationContextCallback: "); callbacks[6] = new com.ibm.wsspi.security.auth.callback. WSTokenHolderCallback ("Authz Token List: "); try { callbackHandler.handle(callbacks); } catch (Exception e) { // Handles exceptions throw new WSLoginFailedException (e.getMessage(), e); } // Sees which callbacks contain information uid = ((NameCallback) callbacks[0]).getName(); char password[] = ((PasswordCallback) callbacks[1]).getPassword(); byte[] credToken = ((WSCredTokenCallbackImpl) callbacks[2]).getCredToken(); javax.servlet.http.HttpServletRequest request = ((WSServletRequestCallback) callbacks[3]).getHttpServletRequest(); javax.servlet.http.HttpServletResponse response = ((WSServletResponseCallback) callbacks[4]).getHttpServletResponse(); java.util.Map appContext = ((WSAppContextCallback) callbacks[5]).getContext(); java.util.List authzTokenList = ((WSTokenHolderCallback) callbacks[6]).getTokenHolderList(); // Gets the SHARED STATE information principal = (WSPrincipal) _sharedState.get(com.ibm.wsspi.security. auth.callback.Constants.WSPRINCIPAL_KEY); credential = (WSCredential) _sharedState.get(com.ibm.wsspi.security. auth.callback.Constants.WSCREDENTIAL_KEY); defaultAuthzToken = (AuthorizationToken) _sharedState.get(com.ibm. wsspi.security.auth.callback.Constants.WSAUTHZTOKEN_KEY); // What you tend to do with this information depends upon the scenario // that you are trying to accomplish. This example demonstrates how to // access various different information: // - Determine if a login is initial versus propagation // - Deserialize a custom authorization token (For more information, see // Propagation des attributs de sécurité // - Add a new custom authorization token (For more information, see // Propagation des attributs de sécurité // - Look for a WSCredential and read attributes, if found. // - Look for a WSPrincipal and read attributes, if found. // - Look for a default AuthorizationToken and add attributes, if found. // - Read the header attributes from the HttpServletRequest, if found. // - Add an attribute to the HttpServletResponse, if found. // - Get the web application name from the appContext, if found. // - Determines if a login is initial versus propagation. This is most // useful when login module is first. boolean requiresLogin = ((WSTokenHolderCallback) callbacks[6]).requiresLogin(); // initial login - asserts privilege attributes based on user identity if (requiresLogin) { // If you are validating a token from another server, there is an // application programming interface (API) to get the uniqueID from it. if (credToken != null && uid == null) { try { String uniqueID = WSSecurityPropagationHelper. validateLTPAToken(credToken); String realm = WSSecurityPropagationHelper.getRealmFromUniqueID (uniqueID); // Now set it to the UID so you can use that to either map or // login with. uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID); } catch (Exception e) { // handle exception } } // Adds a Hashtable to shared state. // Note: You can perform custom mapping on the NameCallback value returned // to change the identity based upon your own mapping rules. uid = mapUser (uid); // Gets the default InitialContext for this server. javax.naming.InitialContext ctx = new javax.naming.InitialContext(); // Gets the local UserRegistry object. com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere.security. UserRegistry) ctx.lookup("UserRegistry"); // Gets the user registry uniqueID based on the uid specified in the // NameCallback. String uniqueid = reg.getUniqueUserId(uid); uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID); // Gets the display name from the user registry based on the uniqueID. String securityName = reg.getUserSecurityName(uid); // Gets the groups associated with this uniqueID. java.util.List groupList = reg.getUniqueGroupIds(uid); // Creates the java.util.Hashtable with the information you gathered from // the UserRegistry. java.util.Hashtable hashtable = new java.util.Hashtable(); hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_UNIQUEID, uniqueid); hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_SECURITYNAME, securityName); hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_GROUPS, groupList); // Adds a cache key that is used as part of the lookup mechanism for // the created Subject. The cache key can be an Object, but should // implement the toString() method. Make sure the cacheKey contains // enough information to scope it to the user and any additional // attributes that you use. If you do not specify this property the // Subject is scoped to the WSCREDENTIAL_UNIQUEID returned, by default. hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_CACHE_KEY, "myCustomAttribute" + uniqueid); // Adds the hashtable to the sharedState of the Subject. _sharedState.put(com.ibm.wsspi.security.token.AttributeNameConstants. WSCREDENTIAL_PROPERTIES_KEY,hashtable); } // propagation login - process propagated tokens else { // - Deserializes a custom authorization token. For more information, see // Propagation des attributs de sécurité. // This can be done at any login module plug in point (first, // middle, or last). if (authzTokenList != null) { // Iterates through the list looking for your custom token for (int i=0; i<authzTokenList.size(); i++) { TokenHolder tokenHolder = (TokenHolder)authzTokenList.get(i); // Looks for the name and version of your custom AuthorizationToken // implementation if (tokenHolder.getName().equals("com.ibm.websphere.security.token. CustomAuthorizationTokenImpl") && tokenHolder.getVersion() == 1) { // Passes the bytes into your custom AuthorizationToken constructor // to deserialize customAuthzToken = new com.ibm.websphere.security.token. CustomAuthorizationTokenImpl(tokenHolder.getBytes()); } } } // - Adds a new custom authorization token (For more information, // see Propagation des attributs de sécurité) // This can be done at any login module plug in point (first, middle, // or last). else { // Gets the PRINCIPAL from the default AuthenticationToken. This must // match all of the tokens. defaultAuthToken = (com.ibm.wsspi.security.token.AuthenticationToken) sharedState.get(com.ibm.wsspi.security.auth.callback.Constants. WSAUTHTOKEN_KEY); String principal = defaultAuthToken.getPrincipal(); // Adds a new custom authorization token. This is an initial login. // Pass the principal into the constructor customAuthzToken = new com.ibm.websphere.security.token. CustomAuthorizationTokenImpl(principal); // Adds any initial attributes if (customAuthzToken != null) { customAuthzToken.addAttribute("key1", "value1"); customAuthzToken.addAttribute("key1", "value2"); customAuthzToken.addAttribute("key2", "value1"); customAuthzToken.addAttribute("key3", "something different"); } } } // - Looks for a WSCredential and read attributes, if found. // This is most useful when plugged in as the last login module. if (credential != null) { try { // Reads some data from the credential String securityName = credential.getSecurityName(); java.util.ArrayList = credential.getGroupIds(); } catch (Exception e) { // Handles exceptions throw new WSLoginFailedException (e.getMessage(), e); } } // - Looks for a WSPrincipal and read attributes, if found. // This is most useful when plugged as the last login module. if (principal != null) { try { // Reads some data from the principal String principalName = principal.getName(); } catch (Exception e) { // Handles exceptions throw new WSLoginFailedException (e.getMessage(), e); } } // - Looks for a default AuthorizationToken and add attributes, if found. // This is most useful when plugged in as the last login module. if (defaultAuthzToken != null) { try { // Reads some data from the defaultAuthzToken String[] myCustomValue = defaultAuthzToken.getAttributes ("myKey"); // Adds some data if not present in the defaultAuthzToken if (myCustomValue == null) defaultAuthzToken.addAttribute ("myKey", "myCustomData"); } catch (Exception e) { // Handles exceptions throw new WSLoginFailedException (e.getMessage(), e); } } // - Reads the header attributes from the HttpServletRequest, if found. // This can be done at any login module plug in point (first, middle, // or last). if (request != null) { java.util.Enumeration headerEnum = request.getHeaders(); while (headerEnum.hasMoreElements()) { System.out.println ("Header element: " + (String)headerEnum.nextElement()); } } // - Adds an attribute to the HttpServletResponse, if found // This can be done at any login module plug in point (first, middle, // or last). if (response != null) { response.addHeader ("myKey", "myValue"); } // - Gets the web application name from the appContext, if found // This can be done at any login module plug in point (first, middle, // or last). if (appContext != null) { String appName = (String) appContext.get(com.ibm.wsspi.security.auth. callback.Constants.WEB_APP_NAME); } return succeeded; } public boolean commit() throws LoginException { boolean succeeded = true; // Add any objects here that you have created and belong in the // Subject. Make sure the objects are not already added. If you added // any sharedState variables, remove them before you exit. If the abort() // method gets called, make sure you cleanup anything added to the // Subject here. if (customAuthzToken != null) { // Sets the customAuthzToken token into the Subject try { // Do this in a doPrivileged code block so that application code // does not need to add additional permissions java.security.AccessController.doPrivileged(new java.security.PrivilegedAction() { public Object run() { try { // Adds the custom authorization token if it is not // null and not already in the Subject if ((customAuthzTokenPriv != null) && (!_subject.getPrivateCredentials().contains(customAuthzTokenPriv))) { _subject.getPrivateCredentials().add(customAuthzTokenPriv); } } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } return null; } }); } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } } return succeeded; } public boolean abort() throws LoginException { boolean succeeded = true; // Makes sure to remove all objects that have already been added (both into the // Subject and shared state). if (customAuthzToken != null) { // remove the customAuthzToken token from the Subject try { final AuthorizationToken customAuthzTokenPriv = customAuthzToken; // Do this in a doPrivileged block so that application code does not need // to add additional permissions java.security.AccessController.doPrivileged(new java.security.PrivilegedAction() { public Object run() { try { // Removes the custom authorization token if it is not // null and not already in the Subject if ((customAuthzTokenPriv != null) && (_subject.getPrivateCredentials(). contains(customAuthzTokenPriv))) { _subject.getPrivateCredentials(). remove(customAuthzTokenPriv); } } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } return null; } }); } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } } return succeeded; } public boolean logout() throws LoginException { boolean succeeded = true; // Makes sure to remove all objects that have already been added // (both into the Subject and shared state). if (customAuthzToken != null) { // Removes the customAuthzToken token from the Subject try { final AuthorizationToken customAuthzTokenPriv = customAuthzToken; // Do this in a doPrivileged code block so that application code does // not need to add additional permissions java.security.AccessController.doPrivileged(new java.security. PrivilegedAction() { public Object run() { try { // Removes the custom authorization token if it is not null and not // already in the Subject if ((customAuthzTokenPriv != null) && (_subject. getPrivateCredentials(). contains(customAuthzTokenPriv))) { _subject.getPrivateCredentials().remove(customAuthzTokenPriv); } } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } return null; } }); } catch (Exception e) { throw new WSLoginFailedException (e.getMessage(), e); } } return succeeded; } }
- Configurez la connexion système pour votre module de connexion personnalisé.
Une fois que vous avez développé votre module de connexion personnalisé pour une configuration de connexion de système, vous pouvez configurer la connexion du système à l'aide de la console d'administration ou de l'utilitaire wsadmin. Pour configurer la connexion de 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. Pour plus d'informations sur le recours à l'utilitaire wsadmin pour la configuration de connexion de système, voir Personnalisation de l'authentification JAAS (Java Authentication and Authorization Service) côté serveur et de la configuration de connexion. Consultez également cet article pour plus d'informations sur les modules de connexion de système et pour déterminer si des modules de connexion supplémentaires doivent être ajoutés.
Sous-rubriques
Personnalisation de la connexion d'application avec le service JAAS (Java Authentication and Authorization Service)
A l'aide de JAAS (Java Authentication and Authorization Service), vous pouvez personnaliser la connexion à l'application.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_jaascustlogmod
Nom du fichier : tsec_jaascustlogmod.html