Implémentation d'un jeton de connexion unique personnalisé pour la propagation des attributs de sécurité

Vous pouvez créer votre propre implémentation de jeton de connexion unique. Celle-ci est définie dans le sujet de la connexion et ajoutée à la réponse HTTP en tant que cookie HTTP.

1. Ecrivez une implémentation personnalisée de l'interface SingleSignonToken.

   Différentes méthodes sont disponibles pour implémenter l'interface SingleSignonToken. Toutefois, assurez-vous que les méthodes requises par l'interface SingleSignonToken et l'interface du jeton sont entièrement implémentées.

   Après avoir implémenté cette interface, vous pouvez la placer dans leapp_server_root/classes:NONE. Une autre solution consiste à placer la classe dans un répertoire privé quelconque. Toutefois, assurez-vous que le chargeur de classe WebSphere Application Server peut localiser la classe et qu'il possède les droits d'accès appropriés. Vous pouvez ajouter le fichier ou le répertoire d'archive Java™ (JAR) contenant cette classe dans leserver.policy fichier afin qu’il dispose des autorisations requises pour le code du serveur.

   Après avoir implémenté cette interface, vous pouvez la placer dans leprofile_root/classes:NONE. Pour plus d'informations sur les cours, voir Création d'un sous-répertoire de classes dans votre profil pour les classes personnalisées.

   Conseil: Tous les types de jetons définis par l'infrastructure de propagation ont des interfaces similaires. En un mot, les types de jetons sont des interfaces de marqueur qui implémentent l'interface com.ibm.wsspi.security.token.Token. Cette interface définit la plupart des méthodes. Si vous prévoyez d'implémenter plusieurs types de jeton, envisagez la création d'une classe abstraite qui implémente l'interface com.ibm.wsspi.security.token.Token. Toutes vos implémentations de jeton, y compris le jeton de connexion unique, doivent étendre la classe abstraite. La majeure partie du travail est alors terminée.

   Pour voir une implémentation du jeton d'authentification unique, voir Exemple : Un com.ibm.wsspi.security.token.SingleSignonToken mise en œuvre

2. Ajoutez et recevez le jeton de connexion unique personnalisé pendant les connexions WebSphere Application Server.
   En général, cette tâche s'accomplit en ajoutant un module de connexion personnalisé aux diverses configurations de connexion d'applications et de système. Cependant, pour désérialiser les informations, vous devrez connecter un module de connexion personnalisé, dont il est question dans une rubrique ultérieure. Une fois que l'objet est instancié dans le module de connexion, vous pouvez l'ajouter au sujet pendant la méthode commit.

   L'exemple de code dans Exemple : un module de connexion par jeton d'authentification unique personnalisé, montre comment déterminer si la connexion est une connexion initiale ou une connexion de propagation. La différence réside dans le fait que le rappel WSTokenHolderCallback contienne des données de propagation ou non. Si le rappel ne contient pas de données de propagation, initialisez une nouvelle implémentation de jeton de connexion unique personnalisée et définissez-la dans le sujet. Par ailleurs, recherchez le cookie HTTP de la demande HTTP si l'objet de demande HTTP est disponible dans le rappel. Vous pouvez obtenir votre jeton de connexion unique personnalisé à partir d'une connexion par propagation horizontale et à partir de la demande HTTP. Il est toutefois recommandé de rendre le jeton disponible aux deux endroits, ce qui permet aux informations d'arriver jusqu'à tout serveur d'applications frontal, même si ce serveur ne prend pas en charge la propagation.

   Vous pouvez faire en sorte que votre jeton de connexion unique soit en lecture seule dans la phase de validation du module de connexion. Si vous définissez le jeton en lecture seule, il n'est pas possible d'ajouter d'attributs dans vos applications.

   Restriction :

   • Les cookies HTTP sont limités en taille. Les limites de taille doivent figurer dans la documentation de votre navigateur.
   • La phase d'exécution de WebSphere Application Server ne gérant pas les cookies qu'elle ne génère pas, elle n'utilise donc pas ce cookie.
   • Placé dans le sujet, l'objet SingleSignonToken n'a pas d'incidence sur la recherche de mémoire cache sur le sujet si vous renvoyez quelque chose dans la méthode getUniqueID.
3. Obtenez le cookie HTTP à partir de l'objet de demande HTTP pendant la connexion ou à partir d'une application.
   L'exemple de code trouvé dans Exemple : Une récupération de cookie HTTP montre comment vous pouvez récupérer le cookie HTTP de la requête HTTP, décoder le cookie afin qu'il revienne à vos octets d'origine et créer votre personnalisé SingleSignonToken objet à partir des octets.
4. Ajoutez votre module de connexion personnalisé aux configurations de connexion de système WebSphere Application Server qui contiennent déjà le module com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule pour la réception des versions sérialisées de votre jeton de propagation personnalisé.
   Etant donné que ce module de connexion repose sur des informations situées dans l'état sharedState ajouté par le module de connexion com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule, ajoutez ce dernier après le module de connexion com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule.

   Pour plus d'informations sur l'ajout de votre module de connexion personnalisé aux configurations de connexion, voir Développement de modules de connexion personnalisés pour une configuration de connexion système pour JAAS.