Cette rubrique explique comment créer votre propre implémentation
de jeton de propagation, laquelle est définie dans l'unité d'exécution en cours de fonctionnement et propagée en aval.
Pourquoi et quand exécuter cette tâche
Le jeton de propagation par défaut est généralement suffisant pour propager des attributs
qui ne sont pas propres à l'utilisateur. Envisagez d'écrire votre propre implémentation si vous souhaitez
accomplir l'une des tâches suivantes :
- Isoler vos attributs au sein de votre propre implémentation.
- Sérialiser les informations à l'aide de la sérialisation personnalisée. Vous devez désérialiser les octets au niveau de la cible et rajouter ces informations sur l'unité d'exécution. Cette tâche peut aussi inclure un codage et un décodage.
Pour implémenter un jeton de propagation personnalisé, vous devez suivre la
procédure ci-après :
- Ecrivez une implémentation personnalisée de l'interface PropagationToken. Différentes méthodes sont disponibles pour implémenter l'interface PropagationToken. Toutefois, assurez-vous que les méthodes requises par l'interface PropagationToken et
l'interface du jeton sont entièrement implémentées.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Une fois que vous avez implémenté cette interface, vous pouvez la placer dans le répertoire racine_serveur_app/classes.
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 JAR (archive Java™) ou le répertoire contenant cette classe dans le fichierserver.policy de façon à ce qu'il dispose des droits requis pour le code du
serveur.
Une fois que vous avez implementé cette interface,
vous pouvez la placer dans le répertoire racine_profil/classes. Pour plus d'informations sur les
classes, voir Création d'un sous-répertoire de classes dans votre profil pour les classes personnalisées..
Conseil : Tous les types de jeton définis par l'infrastructure de
propagation ont des interfaces similaires. 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 propagation, doivent étendre
la classe abstraite. La majeure partie du travail est alors terminée.
Pour
obtenir un exemple d'implémentation de jeton de propagation, voir Exemple : Implémentation com.ibm.wsspi.security.token.PropagationToken.
- Ajoutez et recevez le jeton d'authentification 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.
Vous pouvez également ajouter l'implémentation à partir d'une application. Cependant, pour désérialiser les informations, vous devrez connecter un module de connexion personnalisé, dont il est question à la rubrique Propagation d'un objet sérialisable personnalisé Java pour la propagation des attributs de sécurité.
La
classe WSSecurityPropagationHelper possède des API utilisées pour définir un jeton de
propagation sur l'unité d'exécution et pour l'extraire de l'unité d'exécution afin
d'effectuer des mises à jour.
L'exemple de code fourni dans Exemple : Module de connexion de jeton de propagation personnalisé indique comment
déterminer si la connexion est initiale ou s'il s'agit d'une connexion par propagation. La différence entre ces types de connexion concerne le fait que le
rappel WSTokenHolderCallback contient des données de propagation ou non. Si le rappel ne
contient pas de données de propagation, initialisez une nouvelle implémentation
de propagation personnalisée et définissez-la sur l'unité d'exécution. Si le rappel
contient des données de propagation, recherchez votre instance TokenHolder de jeton de
propagation personnalisée spécifique, reconvertissez le tableau d'octets en votre objet
PropagationToken client et redéfinissez-le sur l'unité d'exécution. L'exemple de code montre les deux instances.
Vous pouvez ajouter des attributs chaque fois que votre jeton de propagation est ajouté à
l'unité d'exécution. Si vous ajoutez des attributs entre les demandes et les modifications de la méthode getUniqueId, la session du client CSIv2 (Common Secure Interoperability Version 2) sera invalidée de sorte qu'il puisse envoyer les nouvelles informations en aval.
L'ajout d'attributs entre les demandes peut altérer les performances. Dans
de nombreux cas, vous souhaitez que les demandes en aval reçoivent les nouvelles
informations sur le jeton de propagation.
Pour ajouter le jeton de propagation personnalisé à l'unité d'exécution, appelez la méthode
WSSecurityPropagationHelper.addPropagationToken.
Cet appel requiert le droit d'accès de sécurité Java 2 WebSphereRuntimePerMission "setPropagationToken".
- Ajoutez votre module de connexion personnalisé aux
configurations de connexion du système WebSphere Application
Server qui contiennent déjà
le module de connexion com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule pour
la réception des versions sérialisées de votre jeton de propagation personnalisé. Vous pouvez également ajouter ce module de connexion à une connexion d'application où
vous souhaitez générer votre jeton de propagation personnalisé sur l'unité d'exécution
pendant la connexion. Vous pouvez également générer l'implémentation du jeton de propagation personnalisé depuis votre
application.
Cependant, pour la désérialiser, vous devez ajouter l'implémentation aux modules de connexion du système.
Pour savoir comment ajouter 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.