Cette tâche explique comment créer votre propre implémentation
de jeton d'authentification, laquelle est définie dans le sujet de la connexion et propagée en aval.
Pourquoi et quand exécuter cette tâche
Le jeton d'autorisation par défaut est suffisant pour propager des attributs
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 des informations sur l'unité d'exécution. Cette tâche peut aussi inclure un codage et un décodage.
- Affecter l'unicité globale du sujet à l'aide de l'API getUniqueID().
Pour implémenter un jeton
d'autorisation personnalisé, vous devez suivre la procédure ci-après :
- Ecrivez une implémentation personnalisée de l'interface AuthorizationToken. Il existe différentes méthodes d'implémentation de l'interface AuthorizationToken. Toutefois, assurez-vous que les méthodes requises par l'interface AuthorizationToken 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 d'archive Java™
(JAR) ou le répertoire contenant cette classe dans le fichier server.policy de façon à ce qu'il dispose des droits requis par le code du serveur.
Une fois que vous avez implémenté
cette interface, placez-la 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. 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 d'autorisation, peuvent étendre la classe abstraite. La majeure partie du travail est alors terminée.
Pour obtenir un exemple
d'implémentation de jeton d'autorisation, voir Exemple : Implémentation com.ibm.wsspi.security.token.AuthorizationToken
- Ajoutez et recevez le jeton d'autorisation 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 à la rubrique Propagation d'un objet sérialisable personnalisé Java pour la propagation des attributs de sécurité. Une fois que l'objet est instancié
dans le module de connexion, vous pouvez l'ajouter au sujet pendant la méthode commit().
Si vous souhaitez uniquement ajouter au sujet des informations à propager, voir Propagation d'un objet sérialisable personnalisé Java pour la propagation des attributs de sécurité. Si vous souhaitez garantir la propagation des
informations, effectuer votre propre sérialisation personnalisée ou spécifier l'unicité pour les besoins de mise en mémoire cache du sujet, envisagez d'écrire votre propre implémentation AuthorizationToken.
L'exemple de code fourni dans Exemple : Module de connexion AuthorizationToken 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 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 AuthorizationToken personnalisée et définissez-la dans le sujet. Si le rappel
contient des données de propagation, recherchez votre instance AuthorizationToken
TokenHolder personnalisée spécifique, reconvertissez le byte[] en votre objet AuthorizationToken
personnalisé et redéfinissez-le dans le sujet. L'exemple de code montre les deux instances.
Vous pouvez
faire en sorte que votre AuthorizationToken soit en lecture seule dans la phase de validation du module de connexion. Si vous ne définissez pas le jeton en lecture seule, des attributs peuvent être ajoutés dans vos applications.
- 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 d'autorisation personnalisé.
Etant donné que ce module de connexion repose sur des informations situées dans le sharedState ajouté par le module com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule, ajoutez ce dernier après le module com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule. 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.