Propagation des attributs de sécurité

Avec la propagation des attributs de sécurité, WebSphere Application Server peut transmettre les attributs de sécurité (contenu de sujet authentifié et informations de contexte de sécurité) d'un serveur à l'autre dans votre configuration. WebSphere Application Server peut obtenir ces attributs de sécurité à partir d'un registre d'utilisateurs, qui interroge les attributs statiques, ou d'un module de connexion (login) personnalisé, qui interroge les attributs statiques et dynamiques. Les attributs de sécurité dynamiques, par nature personnalisés, peuvent inclure la puissance d'authentification utilisée pour la connexion, l'identité du demandeur d'origine, son emplacement, son adresse IP, etc.

La propagation des attributs de sécurité fournit des services de propagation à l'aide de la sérialisation Java™ pour tous les objets contenus dans le sujet. Toutefois, le code Javadoit être en mesure de sérialiser et de désérialiser ces objets. Le langage de programmation Java indique les règles de sérialisation d'un objet par le code Java. Comme des incidents peuvent se produire avec des plateformes et des versions logicielles différentes, WebSphere Application Server met également à disposition une structure de jeton qui active la fonctionnalité de sérialisation personnalisée. La structure de jeton présente d'autres avantages comme la possibilité d'identifier l'unicité du jeton. Cette unicité détermine la manière dont le sujet (Subject) est placé dans la mémoire cache et le rôle du jeton. La structure du jeton définit quatre interfaces de jeton marqueur qui permettent à la phase d'exécution WebSphere Application Server de déterminer la façon de propager le jeton.

Important : Les jetons personnalisés utilisés dans cette infrastructure ne sont pas utilisés par WebSphere Application Server pour l'autorisation ou l'authentification. L'infrastructure fournit un moyen de notifier WebSphere Application Server que vous souhaitez propager ces jetons d'une façon particulière. WebSphere Application Server gère les détails de propagation, mais pas la sérialisation ou la désérialisation des jetons personnalisés. La sérialisation et la désérialisation de ces jetons personnalisés sont effectuées et gérées par un module de connexion personnalisé.

Avec WebSphere Application Server versions 6.0 et ultérieures, un fournisseur JACC (Java Authorization Contract for Container) personnalisé peut être configuré pour contrôler l'accès aux applications Java Platform, Enterprise Edition (Java EE). Un fournisseur JACC personnalisé peut explorer les attributs de sécurité personnalisés dans le sujet JAAS de l'appelant en prenant des décisions liées au contrôle d'accès.

Lorsqu'une demande est authentifiée, les modules de connexion déterminent s'il s'agit d'une connexion initiale ou d'une connexion par propagation. Une connexion initiale est le processus par lequel les informations de l'utilisateur, généralement un ID utilisateur et un mot de passe, sont authentifiées, et par lequel les interfaces de programmation d'application (API) du registre d'utilisateur distant sont appelées pour contrôler les attributs sécurisés représentant les droits d'accès des utilisateurs. Une connexion par propagation est le processus consistant à valider les informations de l'utilisateur, généralement un jeton LTPA (Lightweight Third Party Authentication), puis à désérialiser une série de jetons constituant à la fois des objets personnalisés et des objets de l'infrastructure de jetons connus de WebSphere Application Server.

Les jetons de marqueur suivants sont introduits dans la structure :
Clé d'accès
La clé d'accès contient la plupart des attributs de sécurité concernant l'autorisation qui sont propagés. Le jeton d'autorisation par défaut est utilisé par le moteur d'autorisation WebSphere Application Server pour prendre les décision d'autorisation Java Platform, Enterprise Edition (Java EE). Les fournisseurs de services peuvent utiliser les implémentations de jeton d'autorisation personnalisées pour isoler leurs données dans un autre jeton, effectuer des opérations de sérialisation et de désérialisation et prendre des décisions d'autorisation personnalisée opportunes à l'aide des informations du jeton. Pour plus d'informations sur la manière d'utiliser et de mettre en oeuvre ce type de jeton, voir Utilisation du jeton de propagation par défaut pour propager les attributs de sécurité et Implémentation d'un jeton de propagation personnalisé pour la propagation des attributs de sécurité.
Jeton de connexion unique
Un jeton SingleSignonToken personnalisé ajouté au sujet est automatiquement ajouté à la réponse sous forme de cookie HTTP et contient les attributs renvoyés aux navigateurs Web. La méthode getName d'interface de jeton et la méthode getVersion définissent le nom du cookie. WebSphere Application Server définit un jeton SingleSignonToken par défaut nommé LtpaToken avec la version 2. Le nom du cookie ajouté est LtpaToken2. N'ajoutez pas d'informations sensibles ou confidentielles, ni de données non chiffrées au cookie de la réponse.

Il est également recommandé d'utiliser le protocole SSL (Secure Sockets Layer) pour protéger la demande chaque fois que vous utiliser des cookies. L'utilisation d'un jeton de connexion unique permet aux utilisateurs Web de s'authentifier une fois pour toutes lorsqu'ils accèdent aux ressources Web de plusieurs systèmes WebSphere Application Server. Un jeton SSO personnalisé étend cette fonctionnalité en ajoutant un traitement personnalisé au scénario de connexion unique. Pour plus d'informations sur les jetons de connexion unique, voir Implémentation d'une connexion unique pour réduire les authentifications d'utilisateur Web. Pour plus d'informations sur la manière d'utiliser et de mettre en oeuvre ce type de jeton, voir Utilisation du jeton de connexion unique par défaut avec la fabrique de jetons personnalisée ou par défaut pour la propagation des attributs de sécurité et Implémentation d'un jeton de connexion unique personnalisé pour la propagation des attributs de sécurité.

Jeton de propagation
Le jeton de propagation n'est pas associé à l'utilisateur authentifié et n'est par conséquent pas stocké dans le sujet. Au lieu de cela, il est stocké sur l'unité d'exécution et suit l'appel en permanence. Lorsqu'une demande est envoyée à un autre serveur, les jetons de propagation de cette unité d'exécution sont envoyés avec la demande et exécutés par le serveur cible. Les attributs stockés sur l'unité d'exécution sont propagés sans tenir compte des commutateurs utilisateur RunAs Java Platform, Enterprise Edition (Java EE).

Le jeton de propagation par défaut surveille et consigne tous les commutateurs utilisateur et hôte. Vous pouvez ajouter des informations supplémentaires au jeton de propagation par défaut à l'aide des interfaces de programmation d'application (API) de WSSecurityHelper. Pour extraire et définir des implémentations personnalisées d'un jeton de propagation, vous pouvez utiliser la classe WSSecurityPropagationHelper. Pour plus d'informations sur la manière d'utiliser et de mettre en oeuvre ce type de jeton, voir Utilisation du jeton de propagation par défaut pour propager les attributs de sécurité et Implémentation d'un jeton de propagation personnalisé pour la propagation des attributs de sécurité.

Jeton d'authentification
Le jeton d'authentification est transmis aux serveurs en aval et contient l'identité de l'utilisateur. Ce type de jeton remplit la même fonction que le jeton LTPA (Lightweight Third Party Authentication) des versions précédentes. Même si ce type de jeton est généralement réservé aux utilisations internes de WebSphere Application Server, vous pouvez l'ajouter au sujet. Le jeton est alors propagé à l'aide de la méthode getBytes de l'interface de jeton.

Un jeton d'authentification personnalisé est uniquement utilisé pour les besoins du fournisseur de services, qui l'ajoute au sujet. WebSphere Application Server ne l'utilise pas pour l'authentification, car il existe un jeton d'authentification par défaut utilisé pour l'authentification WebSphere Application Server. Le fournisseur de services utilise ce type de jeton pour déterminer comment les données personnalisées l'utilisent pour prendre des décisions d'authentification personnalisée. Pour plus d'informations sur la manière d'utiliser et de mettre en oeuvre ce type de jeton, voir Jeton d'authentification par défaut et Implémentation d'un jeton d'authentification personnalisé pour la propagation des attributs de sécurité.

Jeton d'authentification Kerberos
Le jeton d'authentification Kerneros contient des informations d'identification, telles que le nom du principal Kerberos et les informations d'identification de délégation GSSCredential et Kerberos. Ce jeton est propagé au serveur aval. Même si ce type de jeton est généralement réservé à des utilisations internes de WebSphere Application Server, s'il contient les données d'identification GSSCredential, vous pouvez utiliser la méthode getGSSCredential pour extraire ces données. Vous pouvez ensuite les placer dans le sujet et les utiliser pour votre application. Ce jeton est créé quand vous vous authentifiez auprès de WebSphere Application Server avec l'authentification SPNEGO Web ou Kerberos.

Propagation horizontale et propagation en aval

Dans WebSphere Application Server, la propagation horizontale, qui utilise une connexion unique pour les demandes Web, et la propagation en aval, qui utilise RMI/IIOP pour accéder aux beans enterprise, sont toutes deux disponibles.

Propagation horizontale

Dans le cadre de la propagation horizontale, les attributs de sécurité sont propagés sur les serveurs frontaux. Les attributs de sécurité sérialisés, qui sont le contenu du sujet et les jetons de propagation (PropagationTokens), peuvent être des attributs statiques ou dynamiques. Le jeton de connexion unique (SSO) stocke les informations supplémentaires propres au système qui sont requises pour la propagation horizontale. Ces informations indiquent au serveur de réception l'emplacement du serveur d'origine et la façon de communiquer avec ce serveur. Par ailleurs, le jeton SSO contient la clé de consultation des attributs sérialisés. Pour permettre la propagation horizontale, vous devez configurer le jeton de connexion unique et les fonctions de propagation des attributs de sécurité Web en entrée. Vous pouvez configurer ces deux fonctions à l'aide de la console d'administration.

Lorsque les serveurs frontaux sont configurés et que dans le même domaine de réplication DRS (Data Replication Service), le serveur d'applications propage automatiquement les informations sérialisées à tous les serveurs du même domaine. Sur la figure 1, l'application 1 est déployée sur le serveur 1 et sur le serveur 2. Les deux serveurs appartiennent au même domaine de réplication DRS. Si une demande provient de l'application 1 sur le serveur 1, puis est redirigée vers l'application 1 sur le serveur 2, les attributs de connexion initiaux se trouvent sur le serveur 2 sans demande distante supplémentaire.

En revanche, si la demande provient de l'application 1, sur le serveur 1 ou 2, mais que la demande est redirigée vers l'application 2 sur le serveur 1 ou 2, les informations sérialisées ne se trouvent pas dans la mémoire cache DRS car les serveurs ne sont pas configurés dans le même domaine de réplication. Ainsi, une demande JMX (Java Management Extensions) distante est renvoyée au serveur d'origine qui héberge l'application 1 pour obtenir les informations sérialisées afin que les informations de connexion initiales soient disponibles dans l'application. En obtenant les informations sérialisées à l'aide d'un rappel JMX à distance vers le serveur d'origine, les avantages dont vous pouvez bénéficier sont les suivants :
  • Vous avez accès à la fonction d'extraction des informations de connexion sur le serveur d'origine.
  • Vous n'avez pas besoin d'effectuer des appels de registre à distance car le serveur d'applications peut régénérer le sujet à partir des informations sérialisées. Sans cette possibilité, le serveur d'applications peut transmettre cinq ou six appels à distance distincts.
Figure 1. Propagation horizontalePropagation horizontale

Implications des performances pour la propagation horizontale

Les implications des performances des appels à distance DRS ou JMX dépendent de l'environnement. L'appel à distance DRS ou JMX permet d'obtenir des attributs de connexion initiaux. La propagation horizontale réduit un grand nombre d'appels de registre utilisateur à distance dans les cas où ces appels pourraient entraîner des soucis de performances pour une application. Cependant, la désérialisation de ces objets peut également causer une dégradation des performances, mais celle-ci peut être inférieure à celle causée par des appels de registre utilisateur à distance. Il est recommandé de tester l'environnement avec la propagation horizontale activée et désactivée. Lorsque vous devez utiliser la propagation horizontale pour conserver les attributs de connexion initiaux, testez si c'est DRS ou JMX qui offre les meilleures performances dans votre environnement. En général, il est recommandé de configurer DRS pour des raisons de reprise par transfert et de performances. Cependant, dans la mesure où DRS propage les informations à tous les serveurs du même domaine de réplication (selon que la propagation accède ou non à tous les serveurs), il peut y avoir une dégradation des performances si le nombre de serveurs qui se trouvent dans le même domaine de réplication est trop important. En pareil cas, réduisez le nombre de serveurs dans le domaine de réplication ou ne configurez pas les serveurs dans un domaine de réplication DRS. Dans le cas de cette dernière suggestion, un appel à distance JMX extrait les attributs, lorsque cela est nécessaire, ce qui peut s'avérer plus rapide globalement.

Cache de sécurité (WSSecureMap)

Dans la figure 1, le cache de sécurité (WSSecureMap) est le cache dynamique utilisé pour la propagation des attributs de sécurité. Le cache WSSecureMap stocke les attributs de sécurité utilisés pour recréer les données d'identification utilisateur ; il évolue avec le nombre d'utilisateurs connectés. La durée de vie par défaut de WSSecureMap est identique au délai d'attente des jetons LTPA. En d'autres termes, les entrées de cache WSSecureMap sont libérées lorsque l'utilisateur se déconnecte. Le modèle d'utilisation pour WSSecureMap est standard.

Vous définissez la taille du cache WSSecureMap dans la console d'administration (Sécurité > Sécurité globale > Propriétés personnalisées > Nouveau) et vous définissez com.ibm.ws.security.WSSecureMapInitAtStartup et com.ibm.ws.security.WSSecureMapSize pour déterminer le mode d'utilisation du cache.

Propagation en aval

Dans le cas d'une propagation en aval, un sujet est généré au niveau du serveur Web frontal, par une connexion par propagation ou une connexion par registre d'utilisateurs. WebSphere Application Server propage les informations de sécurité en aval pour les appels de beans enterprise lorsque les propagations de communications sortantes et entrantes RMI (Remote Method Invocation) sont toutes les deux activées.

Avantages de la propagation des attributs de sécurité

La fonctionnalité de propagation des attributs de sécurité de WebSphere Application Server présente les avantages suivants :

  • Permet à WebSphere Application Server d'utiliser les informations des attributs de sécurité pour des besoins d'authentification et d'autorisation. La propagation des attributs de sécurité peut éviter d'effectuer des appels du registre d'utilisateurs à chaque tronçon distant d'un appel. Les versions précédentes de WebSphere Application Server propagaient uniquement le nom de l'utilisateur authentifié et ignoraient les autres informations sur les attributs de sécurité, qui devaient être générées à nouveau en aval par des appels au registre d'utilisateurs distants. L'exemple suivant illustre les avantages de cette nouvelle fonctionnalité :

    Dans les versions précédentes, il est possible d'utiliser un serveur proxy inverse (RPSS), tel que WebSEAL, pour authentifier l'utilisateur, regrouper les informations de groupe et d'autres attributs de sécurité. Comme indiqué précédemment, WebSphere Application Server acceptait l'identité de l'utilisateur authentifié, mais ignorait les informations d'attributs de sécurité supplémentaires. Pour créer un sujet JAAS (Java Authentication and Authorization Service) contenant les objets WSCredential et WSPrincipal requis, WebSphere Application Server effectuait 5 ou 6 appels au registre d'utilisateurs. L'objet WSCredential contient différentes informations de sécurité requises pour autoriser une ressource Java EE. L'objet WSPrincipal contient le nom du domaine et l'utilisateur qui représente le principal pour le sujet.

    Dans la version actuelle du produit, les informations obtenues à partir du serveur proxy inverse peuvent être utilisées par WebSphere Application Server et propagées en aval vers d'autres ressources du serveur sans effectuer d'appels supplémentaires au registre d'utilisateurs. La conservation des informations sur les attributs de sécurité permet de protéger correctement les ressources du serveur en prenant les décisions de confiance et d'autorisation appropriées. Les permutations d'utilisateur qui se produisent en raison des configurations RunAs Java EE n'entraînent pas la perte des informations du demandeur d'origine par le serveur d'applications. Ces informations sont stockées dans le jeton de propagation situé sur l'unité d'exécution.

  • Permet aux fournisseurs tiers d'ajouter des jetons personnalisés. L'interface de jeton contient une méthode getBytes qui permet à l'implémentation du jeton de définir la sérialisation personnalisée et/ou les méthodes de chiffrement.
  • Permet d'avoir plusieurs jetons du même type dans un sujet créé par différents fournisseurs. WebSphere Application Server peut gérer plusieurs jetons pour une même utilisation. Par exemple, le sujet peut contenir plusieurs jetons d'autorisation, et chacun des jetons peut avoir des attributs d'autorisation distincts générés par différents fournisseurs.
  • Permet de disposer d'un ID unique pour chaque type de jeton utilisé afin de formuler un identifiant de sujet plus unique que le seul nom d'utilisateur dans les cas où les attributs dynamiques sont susceptibles de modifier le contexte d'une connexion d'utilisateur. Le type de jeton possède une méthode getUniqueId() utilisée pour renvoyer une chaîne unique pour des besoins de mise en mémoire cache. Par exemple, il se peut que vous deviez propager un ID d'emplacement, qui indique l'emplacement à partir duquel l'utilisateur se connecte au système. Cet ID d'emplacement peut être généré pendant la connexion d'origine à l'aide d'un serveur proxy inverse ou de la configuration de connexion WEB_INBOUND et ajouté au sujet avant la sérialisation. D'autres attributs peuvent être ajoutés au sujet et utiliser un ID unique. Tous les ID uniques doivent être pris en compte pour l'unicité du sujet entier. WebSphere Application Server peut définir ce qui est unique dans les informations contenues dans le sujet, ce qui peut affecter la manière dont l'utilisateur accédera au sujet ultérieurement.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_secattributeprop
Nom du fichier : csec_secattributeprop.html