Configuration des filtres d'authentification

Les filtres d'authentification du portail utilisent le même schéma que celui défini par l'utilitaire de filtre de servlet J2EE. Pour plus d'informations, voir The Essentials of Filters. L'exemple suivant décrit de quelle manière ce pattern est appliqué aux filtres d'authentification.

Trigger of filter chain, |                        |
   for example explicit  |   CustomFilter1        |
   login or logout      ---> next(..., chain){    |                         |
                         |   // do something #1a  |   CustomFilter2         |
                         |   chain.next(...)     ---> next(..., chain){     |
                         |                        |   // do something #2a   |   DefaultFilter
                         |                        |   chain.next(...)      ---> next(..., chain){
                         |                        |                         |   // Execute the
                         |                        |                         |      default logic
                         |                        |   // do something #2b <---  }
                         |  // do something #1b <---  }                     |  
Redirect, exception,   <--- }                     |  
   or continue           | 

Un filtre par défaut réalise la logique par défaut d'un cas d'utilisation spécifique, par exemple la connexion. Vous pouvez regrouper en chaîne un ensemble de filtres personnalisés à exécuter avant le filtre par défaut. Lorsque la chaîne de filtres est démarrée, elle appelle le premier élément de la chaîne (dans l'exemple, il s'agit de CustomFilter1) et transmet un objet de chaîne à l'appel sous forme d'argument. L'implémentation du filtre peut alors effectuer certaines opérations qu'elle appelle pour réaliser la méthode appropriée sur l'objet de chaîne afin de déclencher l'élément suivant dans la chaîne (CustomFilter2). Ce filtre peut à nouveau implémenter une logique particulière qui est exécutée avant l'appel de l'élément suivant. Le dernier élément de la chaîne est l'élément DefaultFilter prédéfini, lequel garantit l'exécution de la logique par défaut du cas d'utilisation concerné.

Le concept de chaîne de filtres décrit dans la section précédente est appliqué à six types d'événement affectant les flux de connexion, de déconnexion et de traitement de session Portal. Ceci assure une approche flexible permettant d'adjoindre une logique personnalisée à chacun de ces flux. Des chaînes de filtre existent notamment pour les événements suivants :

• Connexion explicite : connexion à l'aide d'un nom d'utilisateur et d'un mot de passe, comme représenté par l'interface com.ibm.portal.auth.ExplicitLoginFilter. Par exemple, connexion en utilisant le portlet ou l'URL de connexion.
• Connexion implicite : par exemple, lorsqu'un utilisateur est déjà authentifié par WAS, mais pas encore auprès de Portal. Cet événement est représenté par l'interface com.ibm.portal.auth.ImplicitLoginFilter.
• Déconnexion explicite : cela signifie que l'utilisateur déclenche directement une action de déconnexion, par exemple en cliquant sur Déconnexion dans l'interface utilisateur, interface com.ibm.portal.auth.ExplicitLogoutFilter.
• Déconnexion implicite : par exemple, à expiration du délai de session, ou lorsqu'un utilisateur authentifié accède à une page publique, ou à un portail virtuel sans être membre du domaine utilisateurs associé. Cet événement est représenté par l'interface com.ibm.portal.auth.ImplicitLogoutFilter.
• Expiration du délai d'attente de session : appelée immédiatement au terme du délai d'inactivité de la session de l'utilisateur. Cet événement est représenté par l'interface com.ibm.portal.auth.SessionTimeoutFilter.
• Validation de session : appelée pour chaque requête avant que ne soient déclenchées des actions et un rendu de la page. Cet événement est représenté par l'interface com.ibm.portal.auth.SessionValidationFilter.

A part le filtre de délai d'attente de session, chacun des filtres ci-dessus a accès aux objets de demande et de réponse HTTP. Un objet de contexte spécial peut être utilisé pour partager des informations entre les filtres et définir les redirections exécutées après le traitement de la chaîne de filtres. Pour plus de détails sur chacun des filtres et sur les interfaces de chaîne de filtres, voir la documentation relative à HCL Portal et à l'API JavaDoc. Pour obtenir un exemple de chaîne de filtres, voir la rubrique Exemple de filtre d'authentification personnalisé.

Vous pouvez spécifier l'ordre de chacun des filtres de la chaîne en configurant les propriétés suivantes dans le service d'authentification WP du portail :

login.explicit.filterchain    = colon or semicolon-separated list of fully qualified class names
login.implicit.filterchain    = colon or semicolon-separated list of fully qualified class names
logout.explicit.filterchain   = colon or semicolon-separated list of fully qualified class names
logout.implicit.filterchain   = colon or semicolon-separated list of fully qualified class names
sessiontimeout.filterchain    = colon or semicolon-separated list of fully qualified class names
sessionvalidation.filterchain = colon or semicolon-separated list of fully qualified class names

De plus, vous pouvez configurer des propriétés dans le service d'authentification WP du portail d'après le schéma suivant :

filterchain.properties.fully qualified class name of the filter implementation.property name

Cela a pour effet de rendre disponible la valeur de la propriété dans l'objet de configuration de filtre de la classe spécifiée en utilisant la clé property name.

Un exemple de filtre personnalisé intégré dans la chaîne de filtre de connexion explicite au portail figure ci-dessous. Le filtre personnalisé contient des propriétés qui définissent des URL de redirection données correspondant à des ID utilisateur spécifiques et déclenche la redirection correspondante lorsque la connexion de l'un de ces utilisateurs aboutit. Pour implémenter un exemple de ce type, procédez comme suit :

1. Implémentez l'interface com.ibm.portal.auth.ExplicitLoginFilter et rendez votre classe disponible dans le chemin d'accès aux classes du portail en ajoutant le fichier JAR au répertoire de chemin d'accès aux classes étendu de l'application HCL : PortalServer_root/shared/app. Pour un exemple d'implémentation des méthodes de l'interface, reportez-vous à l'exemple de code suivant :

   package com.ibm.portal.example;
   
   public class UserRedirectLoginFilter implements ExplicitLoginFilter {
   	
       // hash map to store the mappings from user id to redirect URL
          private java.util.Map userToRedirectURLs = new java.util.HashMap();
   
   public void init(SecurityFilterConfig filterConfig)
          throws SecurityFilterInitException {
       // iterate the list of init parameters and store 
          the mappings of user to redirect urls for 
          (java.util.Iterator it = filterConfig.getInitParameterNames(); it.hasNext(); ) {
              String currentParameter = (String)it.next();
              userToRedirectURLs.put(currentParameter, 
              filterConfig.getInitParameter(currentParameter));
           }
       }
   
       public void login(HttpServletRequest req, HttpServletResponse resp,
                   String userID, char[] password,
                   FilterChainContext portalLoginContext, Subject subject,
                   String realm, ExplicitLoginFilterChain chain)
                   throws LoginException, WSSecurityException,
                   PasswordInvalidException, UserIDInvalidException,
                   AuthenticationFailedException, AuthenticationException,
                   SystemLoginException, com.ibm.portal.auth.exceptions.LoginException {
           // call the next element in the filter chain to trigger the default login
              chain.login(req, resp, userID, password, portalLoginContext, subject, realm);
   		
           // if no exception occured, the login was successful
              if (userToRedirectURLs.containsKey(userID)) {
           // set the redirect url for the user if we have an entry
              portalLoginContext.setRedirectURL((String)userToRedirectURLs.get(userID));
           }
       }
   
       public void destroy() {
              // nothing to do here
       }
    }
   

2. Spécifiez le nom de classe du filtre personnalisé dans les propriétés du service d'authentification WP :

   login.explicit.filterchain=com.ibm.portal.example.UserRedirectLoginFilter

3. Pour définir les URL de redirection d'ID utilisateur spécifiques, spécifiez en conséquence le groupe de propriétés personnalisées de cette classe. Exemple :

   filterchain.properties.com.ibm.portal.example.UserRedirectLoginFilter.alice=/wps/myportal/pageA
   filterchain.properties.com.ibm.portal.example.UserRedirectLoginFilter.bob=/wps/myportal/pageB

4. Redémarrez le portail.

Le nouveau filtre de connexion explicite sera à présent actif. Les utilisateurs définis dans les propriétés seront redirigés vers les URL spécifiées après leur connexion via le portlet ou l'URL de connexion.