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.
Pourquoi et quand exécuter cette tâche
Le nom du cookie correspond à la concaténation de
l'API SingleSignonToken.getName et de l'API SingleSignonToken.getVersion. Il n'y a pas de délimiteur. Lorsque vous ajoutez un jeton de connexion unique au sujet, il est également
propagé horizontalement et en aval si le sujet est utilisé pour d'autres
demandes Web. Vous devez
désérialiser votre jeton de connexion unique lorsque vous le recevez à partir d'une
connexion de propagation. 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. Chiffrez ces
informations car elles se trouvent en dehors de la
réponse HTTP et sont disponibles sur Internet. Vous devez désérialiser ou décrypter les octets au niveau de la cible et rajouter ces informations dans le sujet.
- Affecter l'unicité globale au sujet à l'aide de l'API getUniqueID.
Pour implémenter un jeton de connexion unique personnalisé, suivez la procédure ci-après :
- 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.
![[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. 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 obtenir un exemple d'implémentation de jeton de connexion unique, voir Exemple : Implémentation com.ibm.wsspi.security.token.SingleSignonToken
- 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 fourni dans Exemple : Un module de connexion de jeton de connexion unique personnalisé indique comment déterminer
si la connexion est initiale ou s'il s'agit d'une connexion par 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.
- Obtenez le cookie HTTP à partir de l'objet de demande HTTP pendant la connexion ou à partir d'une application. L'exemple de code fourni dans Exemple : Extraction de cookie HTTP explique comment extraire le cookie HTTP de la demande HTTP, décoder le cookie afin qu'il revienne à vos octets d'origine, et créer votre propre objet SingleSignonToken personnalisé à partir des octets.
- 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.