Authentification

L'authentification de sécurité Liberty permet de confirmer l'identité d'un utilisateur.

Pour pouvoir accéder à une ressource Web protégée, l'utilisateur doit fournir des données d'identification, comme un ID utilisateur et un mot de passe. Le processus d'authentification implique de recueillir ces données d'identification (selon un procédé qui varie en fonction de la manière dont l'application Web a été configurée pour obtenir ces données) et de les valider par rapport au registre configuré. Une fois les données d'identification vérifiées, un sujet JAAS est créé pour cet utilisateur. Il contient des informations supplémentaires sur l'utilisateur, comme les groupes auxquels l'utilisateur appartient et les jetons créés pour l'utilisateur. Les informations regroupées dans ce sujet sont ensuite utilisées au cours du processus d'autorisation pour déterminer si l'utilisateur peut accéder à la ressource.

Le diagramme suivant illustre un processus d'authentification type pour l'accès à une ressource Web.

Figure 1. Vue d'ensemble du processus d'authentification. Le service d'authentification utilise des modules de connexion JAAS pour traiter l'authentification.

Le processus d'authentification implique la collecte des données d'identification auprès de l'utilisateur, la consultation du cache pour déterminer s'il contient le sujet correspondant à cet utilisateur et, dans la négative, l'appel du service JAAS pour qu'il effectue l'authentification et crée un sujet. Le service JAAS appelle lui-même une série de modules de connexion pour traiter l'authentification. Un ou plusieurs des modules de connexion créent le sujet en fonction des données d'identification. Le module de connexion appelle le registre configuré pour contrôler la validité des données d'identification. Si la validité des données est confirmée, le processus d'authentification collecte et crée des informations adéquates pour cet utilisateur, notamment les groupes auxquels il appartient et le jeton de connexion unique (SSO) utilisé pour la capacité SSO, et les stocke dans le sujet en tant que données d'identification pertinentes. Vous pouvez aussi personnaliser les informations sauvegardées dans le sujet en connectant des modules de connexion personnalisés au cours de ce processus.

Lorsque l'authentification réussit, le jeton SSO créé au cours du processus est renvoyé au navigateur de l'utilisateur dans un cookie. Le nom par défaut du cookie configurable est ltpaToken2. Lors des appels suivants, les informations de jeton sont utilisées pour authentifier l'utilisateur. Si cette authentification échoue, le service d'authentification tente d'utiliser d'autres données d'identification, telles que l'ID utilisateur et le mot de passe, si elles existent encore dans la demande.
Remarque : Pour que les ID utilisateur et les mots de passe contenant des caractères autres que des caractères US-ASCII soient pris en charge, la méthode de connexion par formulaire est requise pour les applications Web. Pour plus d'informations, voir autoRequestEncoding and autoResponseEncoding.

Registres d'utilisateurs

Pour contrôler la validité des données d'authentification d'un utilisateur, les modules de connexion appellent le registre d'utilisateurs configuré à cet effet. Le profil Liberty peut fonctionner tant avec un registre d'utilisateurs simple, dont les entrées sont créées directement dans la configuration, qu'avec un référentiel plus robuste basé sur le protocole LDAP. Pour plus d'informations, voir Configuration d'un registre d'utilisateurs pour le profil Liberty.

Avec le registre LDAP, vous pouvez aussi fédérer plusieurs référentiels et exécuter les opérations LDAP dans plusieurs registres. L'utilisateur de profil Liberty peut configurer la fonction de fédération de registre LDAP directement dans le fichier server.xml ou dans la section de la fédération de registre LDAP de l'outil de développement. Une fois les référentiels fédérés configurés, vous pouvez obtenir un résultat consolidé des référentiels fédérés pour n'importe quelle opération. Par exemple, si vous voulez exécuter une opération de recherche de tous les noms d'utilisateur qui commencent par test, vous pouvez lancer une recherche dans l'ensemble de registres LDAP et obtenir un résultat de recherche consolidé qui peut ensuite être renvoyé au programme appelant.

Cache d'authentification

Comme la création d'un sujet est relativement coûteuse, le profil Liberty fournit un cache d'authentification pour permettre le stockage du sujet une fois qu'un utilisateur a été authentifié correctement. Par défaut, le cache est paramétré avec un délai d'expiration de 10 minutes. Si l'utilisateur ne se reconnecte pas dans les 10 minutes, le sujet correspondant est retiré du cache et le processus d'authentification complet doit alors être répété pour créer un nouveau sujet pour cet utilisateur. Les modifications apportées à la configuration et qui ont un impact sur la création du sujet, comme l'ajout d'un module de connexion ou la modification des clés LTPA, entraînent l'effacement des données du cache d'authentification. Si le sujet est mis en cache et que les informations qui figurent dans le registre changent, le cache est mis à jour avec les informations du registre. Vous pouvez configurer le délai d'expiration des entrées en cache ainsi que la taille du cache, et choisir d'activer ou de désactiver la mise en cache. Pour plus d'informations, voir Configuration du cache d'authentification dans le profil Liberty.

Configuration JAAS

La configuration JAAS définit une série de modules de connexion pour créer le sujet. Le profil Liberty prend en charge les configurations JAAS suivantes :
system.WEB_INBOUND
Utilisée lors de l'accès aux ressources Web telles que les servlets et les pages JSP.
WSLogin
Utilisée par les applications lors du développement de modules de connexion de programmation pour JAAS.
system.DEFAULT
Utilisée pour la connexion lorsqu'aucune configuration JAAS n'est spécifiée.
[8.5.5.4 ou ultérieure]system.DESERIALIZE_CONTEXT
[8.5.5.4 ou ultérieure]Utilisé lorsqu'un contexte de sécurité est en cours de désérialisation. Cette configuration JAAS traite l'authentification pour recréer les sujets qui étaient actifs sur l'unité d'exécution au moment de la sérialisation du contexte de sécurité. Vous pouvez indiquer cette configuration JAAS et ajouter vos propres modules de connexion JAAS en éditant l'entrée de configuration JAAS dans le fichier server.xml pour garantir que les sujets propagés contiennent vos informations personnalisées.
Les configurations system.WEB_INBOUND et system.DEFAULT contiennent les modules de connexion par défaut suivants, dans cet ordre : hashtable, userNameAndPassword, certificate, token. Dans la configuration WSLogin, le module de connexion proxy est le module de connexion par défaut, et le proxy délègue toutes les opérations au module de connexion réel dans system.DEFAULT.

Aucune configuration explicite n'est requise sauf si vous voulez procéder à une personnalisation avec vos propres modules de connexion. La ou les configurations de connexion à personnaliser dépendent de vos besoins spécifiques. Par exemple, si vous voulez personnaliser toutes les connexions aux ressources Web, il suffit d'ajouter des modules de connexion personnalisés à la configuration system.WEB_INBOUND. Voir Configuration d'un module de connexion personnalisé JAAS pour le profil Liberty.

Modules de connexion JAAS

La configuration JAAS utilise une série de modules de connexion pour créer le sujet. Le profil Liberty met à disposition une série de modules de connexion dans chaque configuration de connexion. Selon les données d'authentification, un module de connexion particulier crée le sujet. Les données d'authentification sont transmises aux modules de connexion via le gestionnaire d'appel, conformément à la spécification JAAS. Par exemple, si le gestionnaire d'appel utilisé est celui qui invite l'utilisateur à spécifier son ID et son mot de passe, l'authentification est traitée par le module de connexion userNameAndPassword. Si une donnée d'identification SingleSignonTokenest présentée comme donnée d'authentification, le module de connexion token seulement traite l'authentification.

Les modules de connexion par défaut suivants sont pris en charge dans le profil Liberty :
userNameAndPassword
Traite l'authentification lorsque le nom d'utilisateur et le mot de passe sont utilisés comme données d'authentification.
certificate
Traite l'authentification lorsqu'un certificat X509 est utilisé comme données d'authentification pour le protocole SSL mutuel.
token
Traite l'authentification lorsqu'un jeton SSO est présenté comme données d'authentification. Au cours du processus d'authentification, un jeton SSO est créé et renvoyé dans un cookie au client HTTP (navigateur). A chaque demande suivante émanant du même navigateur, ce cookie est renvoyé au serveur, lequel en extrait le jeton et peut ainsi authentifier l'utilisateur si la connexion unique (SSO) est activée.
hashtable
Module utilisé lorsque les données d'authentification sont envoyées via une table de hachage prédéfinie. Pour plus d'informations sur la connexion par table de hachage, voir Module de connexion par table de hachage. Ce module de connexion est également utilisé par l'environnement d'exécution de la sécurité lorsque l'authentification est effectuée avec l'identité uniquement, par exemple dans le cas de runAs.
proxy
Module de connexion par défaut pour WSLogin. Voir Module de connexion par proxy.

Les modules de connexion sont appelés dans l'ordre suivant lequel ils sont configurés. L'ordre par défaut est hashtable, userNameAndPassword, certificate, token. Si vous choisissez de personnaliser le processus de connexion avec vos propres modules de connexion, vous devez les fournir et les configurer dans l'ordre qui répond à vos besoins. En général, il est recommandé de placer un module de connexion personnalisé en premier dans la liste de modules de connexion pour qu'il soit appelé en priorité. Lorsqu'un module de connexion personnalisé est utilisé, vous devez ajouter à la configuration toutes les informations se rapportant aux différents modules utilisés, ainsi que celles du module personnalisé, dans l'ordre requis.

Lorsqu'un module de connexion confirme qu'il peut traiter l'authentification, il s'assure d'abord que les données d'authentification transmises sont valides. Par exemple, dans le cas d'une authentification par nom d'utilisateur et mot de passe, le registre d'utilisateurs configuré est appelé pour vérifier la validité de ces données. Dans le cas d'une authentification par jeton, le jeton doit être déchiffré et sa validité doit être contrôlée.

Une fois les données d'authentification validées, les modules de connexion créent les données d'identification complètes de l'utilisateur (le sujet) en ajoutant des informations telles que ses groupes d'appartenance et son jeton SSO. Un module de connexion personnalisé peut ajouter des données supplémentaires au sujet en créant ses propres données d'identification. Pour que l'autorisation du profil Liberty fonctionne, le sujet doit contenir les données d'identification WSCredential, WSPrincipal et SingleSignonToken. Les données d'identification WSCredential contiennent des informations sur les groupes, ainsi que des informations supplémentaires requises par l'environnement d'exécution de la sécurité.

Gestionnaire d'appel

Le profil Liberty prend en charge divers gestionnaires d'appel pour fournir les données aux modules de connexion dans le cadre du processus d'authentification JAAS. Un module de connexion personnalisé peut utiliser les informations du gestionnaire d'appel afin de s'authentifier. Par exemple, s'il a besoin d'accéder à des informations qui se trouvent dans un objet HttpServletRequest, il peut utiliser ce gestionnaire d'appel spécifique.

Les fabriques et les gestionnaires d'appel suivants conçus pour le développement de modules de connexion de programmation pour JAAS sont pris en charge dans le profil Liberty :
  • com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl
  • com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory
La documentation d'API Java pour chaque API de profil Liberty est détaillée dans la section Interfaces de programmation (API) du centre de documentation et est également disponible dans un fichier .zip distinct dans l'un des sous-répertoires javadoc du répertoire ${wlp.install.dir}/dev.

Voir Développement de modules de connexion JAAS personnalisés pour une configuration de connexion système.

Données d'identification et jetons

Comme mentionné dans la section traitant des modules de connexion, les données d'identification sont créées dans le cadre du processus de création du sujet. Le profil Liberty crée les données d'identification WSCredential, SingleSignonToken et WSPrincipal. Les données d'identification SingleSignonToken contiennent le jeton qui est renvoyé au navigateur dans un cookie pour que la connexion unique fonctionne. Ce jeton contient les informations de l'utilisateur et un délai d'expiration. Il est signé et chiffré à l'aide des clés LTPA (Lightweight Third Party Authentication) qui sont générées au premier démarrage du serveur. Le délai d'expiration par défaut est de 2 heures. Il s'agit d'une durée absolue, qui ne dépend aucunement de l'activité de l'utilisateur. Une fois les 2 heures écoulées, le jeton expire et l'utilisateur doit se reconnecter pour accéder à la ressource.

LTPA

LTPA (Lightweight Third Party Authentication) est conçu pour les environnements à plusieurs serveurs d'applications et distribués. Dans le profil Liberty, LTPA prend en charge la connexion unique et la sécurité dans un environnement distribué via le chiffrement. Ce support permet à LTPA de chiffrer, signer numériquement et transmettre en toute sécurité des données liées à l'authentification, puis de les déchiffrer et de vérifier leur signature.

Le protocole LTPA permet à différents serveurs d'applications de communiquer de façon sécurisée. Il fournit également la fonction de connexion unique, qui permet à un utilisateur de ne s'authentifier que s'il se connecte à un serveur de noms de domaine (DNS). Ensuite, l'utilisateur peut accéder aux ressources qui se trouvent sur d'autres serveurs de profil Liberty dans le même domaine sans avoir à s'authentifier. Les noms de domaine sur chaque système dans le domaine DNS doivent être strictement identiques.

Le protocole LTPA utilise des clés de chiffrement pour chiffrer et déchiffrer les données utilisateur échangées par les serveurs. Ces clés doivent être partagées entre les différents serveurs et ces derniers doivent tous utiliser le même registre d'utilisateurs. Dès lors que ces conditions sont remplies, les ressources hébergées par un serveur peuvent accéder aux ressources d'un autre serveur. LTPA exige que le registre d'utilisateurs configuré soit un référentiel partagé et centralisé, afin que les utilisateurs et groupes soient les mêmes quel que soit le serveur.

Avec LTPA, un jeton contenant les informations de l'utilisateur et un délai d'expiration et signé par les clés est créé. Le jeton LTPA possède une date d'expiration. Il est important que tous les serveurs participants aient leurs horloges synchronisées. Sinon, les jetons LTPA expirent prématurément et font échouer l'authentification ou la validation. Le temps universel coordonné (UTC) est utilisé par défaut, et tous les autres serveurs doivent avoir la même heure UTC. Consultez la documentation relative à votre système d'exploitation pour savoir comment s'assurer que le temps universel coordonné est le même sur tous les serveurs.

Le jeton LTPA est transmis aux autres serveurs par le biais de cookies de ressources Web lorsque SSO est activé.

Si les serveurs recevant le jeton partagent les mêmes clés que le serveur émetteur, ils peuvent le déchiffrer et vérifier qu'il n'a pas expiré et que les informations qu'il contient correspondent à une entrée valide dans le registre d'utilisateurs. Si la validité est confirmée, les ressources hébergées par ces serveurs deviennent accessibles au serveur demandeur, moyennant vérification de ses droits par le processus d'autorisation.

Chaque serveur doit posséder des données d'identification valides. Quand celles-ci expirent, le serveur doit communiquer avec le registre d'utilisateurs pour s'authentifier. Il est tentant d'augmenter la durée de conservation en cache du jeton LTPA, mais cela fait peser un risque légèrement plus élevé sur la sécurité et vous devez en tenir compte au moment de définir votre politique de sécurité.

Si le partage des clés entre différents serveurs de profil Liberty est requis, copiez les clés d'un serveur à l'autre. Pour des raisons de sécurité, les clés sont chiffrées avec une clé générée aléatoirement et leur accès est protégé par un mot de passe que vous définissez. Ce mot de passe est nécessaire au moment de l'importation des clés dans un autre serveur. Le mot de passe est utilisé pour protéger les clés seulement et non pour les générer.

Lorsque la sécurité est activée, LTPA est configuré par défaut au premier démarrage du serveur de profil Liberty. Pour plus d'informations sur le support de LTPA, voir Configuration de l'authentification LTPA dans le profil Liberty.

Référentiel Liberty[8.5.5.5 ou ultérieure]

SPNEGO

Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) permet aux utilisateurs de se connecter au contrôleur de domaine Microsoft une première fois et d'accéder ensuite aux applications protégées sur les serveurs Liberty sans y être à nouveau invité.

Lorsque l'authentification Web SPNEGO est activée, et que le client de navigation accède à une ressource protégée sur le le serveur Liberty, SPNEGO est chargé d'authentifier l'accès à la ressource sécurisée qui est identifiée dans la demande HTTP. Le client de navigation crée un jeton SPNEGO et l'envoie au serveur de profil Liberty dans le cadre de la demande HTTP. WebSphere Application Server valide et extrait l'identité de l'utilisateur depuis le jeton SPNEGO. L'identité permet d'établir un contexte sécurisé entre l'utilisateur et le serveur d'application.

Pour plus d'informations sur SPNEGO, voir Référentiel Liberty[8.5.5.5 ou ultérieure]SPNEGO. Pour plus d'informations sur la configuration de SPNEGO sur le serveur de profil Liberty, voir Référentiel Liberty[8.5.5.5 ou ultérieure]Configuration de l'authentification SPNEGO dans le profil Liberty.

Connexion unique (SSO)

La connexion unique (SSO) permet aux utilisateurs de se connecter à un endroit (un serveur, par exemple) et d'accéder aux applications sur d'autres serveurs sans qu'il leur soit redemandé de s'authentifier. Pour que la connexion unique puisse fonctionner, les clés LTPA doivent être échangées entre les différents serveurs de profil Liberty, le registre d'utilisateurs doit être le même, et le jeton ne doit pas avoir expiré. Pour l'échange des clés LTPA, vous pouvez copier le fichier ltpa.keys d'un serveur à un autre et redémarrer ce dernier afin qu'il utilise les nouvelles clés LTPA. Tous les serveurs participant à un domaine SSO doivent se référer au même registre d'utilisateurs.

Lorsqu'un utilisateur est authentifié sur un premier serveur Liberty, le jeton SSO créé pour cet utilisateur au cours du processus d'authentification est placé dans le cookie qui est envoyé au HTTP (par exemple un navigateur). Si ce même client adresse ensuite une demande d'accès à un groupe d'applications situé sur un serveur différent, mais sur le même serveur de noms de domaine (DNS) que celui qui a été configuré dans le cadre de la configuration de la connexion unique sur le premier serveur, le cookie est envoyé avec la demande. Le serveur recevant cette demande tente alors d'authentifier l'utilisateur avec le jeton contenu dans le cookie. Si les deux conditions sont remplies (le jeton n'a pas expiré et l'utilisateur correspond bien à une entrée valide dans le registre), il valide le jeton et crée un sujet pour cet utilisateur sans lui demander de s'authentifier à nouveau. Si le jeton ne peut pas être validé (par exemple s'il ne peut pas être déchiffré ou s'il ne peut pas être vérifié en raison d'une non-concordance des clés LTPA), l'utilisateur est invité à entrer à nouveau ses données d'identification.

Toute application configurée pour utiliser l'attribut Form-login exige que la connexion unique (SSO) soit configurée pour ce serveur. Lorsque l'utilisateur est authentifié pour une connexion par formulaire (form-login), le jeton est renvoyé au navigateur qui sera utilisé pour autoriser l'utilisateur à accéder à la ressource.

Voir Personnalisation de la configuration de la connexion unique (SSO) avec des cookies LTPA pour le profil Liberty.

Authentification connectable

Il existe différentes techniques de personnalisation du processus d'authentification :

Pour plus de détails sur les modules de connexion JAAS et l'intercepteur de relations de confiance (TAI), voir Advanced authentication in WebSphere Application Server.

Vérification d'identité

En plus de l'authentification qui exige d'une entité de demande qu'elle prouve son identité, le profil Liberty prend également en charge la vérification d'identité. Il s'agit d'une forme souple d'authentification qui ne requiert pas la preuve de l'identité, mais qui accepte l'identité en fonction d'une relation de confiance avec l'entité, qui garantit l'identité vérifiée.

Il existe différentes techniques pour vérifier les identités dans le profil Liberty :
  1. Utilisez la connexion par table de hachage. Voir Développement de modules de connexion JAAS personnalisés pour une configuration de connexion système.
  2. Utilisez IdentityAssertionLoginModule. Vous pouvez autoriser un fournisseur d'applications ou de systèmes à vérifier une identité en procédant à la validation des relations de confiance. Pour utiliser IdentityAssertionLoginModule, servez-vous de l'infrastructure de connexion JAAS, dans laquelle la validation des relations de confiance est effectuée dans un module de connexion personnalisé et la création des données d'identification est effectuée dans IdentityAssertionLoginModule. Vous pouvez utiliser les deux modules de connexion pour créer une configuration de connexion JAAS pouvant ensuite être utilisée pour vérifier une identité.
    Les deux modules de connexion personnalisés suivants sont requis :
    Module implémenté par l'utilisateur (validation des relations de confiance)
    Le module de connexion implémenté par l'utilisateur effectue toutes les vérifications de relation de confiance requises. Une fois la relation de confiance vérifiée, le statut de la vérification de la relation de confiance et l'identité de connexion doivent être placés dans une mappe à l'état partagé du module de connexion pour que le module de connexion qui crée les données d'identification puisse utiliser ces informations. Stockez cette mappe dans la propriété suivante :
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
    Cette propriété possède les propriétés suivantes :
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
      Cette propriété a pour valeur true si la confiance est établie et false dans le cas contraire.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
      Cette propriété contient le principal de l'identité.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
      Cette propriété contient le certificat de l'identité.
    Module de connexion pour la vérification d'identité (création de données d'identification)
    Le module suivant crée les données d'identification :
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule
    Ce module utilise les informations d'état des relations de confiance à l'état partagé du contexte de connexion.
    Le module de connexion pour la vérification d'identité recherche les informations relatives aux relations de confiance dans la propriété d'état partagé :
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
    Cette propriété contient le statut des relations de confiance ainsi que l'identité de connexion, et doit inclure la propriété suivante :
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
      Cette propriété a pour valeur true si la confiance est établie et false dans le cas contraire.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
      Cette propriété contient le principal de l'identité de connexion si un principal est utilisé.
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
      Cette propriété contient un tableau de chaîne de certificat qui comporte l'identité de connexion si un certificat est utilisé.

    Un message WSLoginFailedException est émis s'il manque des données (état, confiance ou identité). Le module de connexion se connecte ensuite avec l'identité, et le sujet contient la nouvelle identité.

    Voir Personnalisation d'une connexion d'application afin d'effectuer une vérification d'identité avec JAAS.

Authentification RunAs()

Une fois que vous êtes authentifié après l'appel d'un servlet, le servlet peut procéder à d'autres appels, de servlets différents par exemple. Normalement, ces appels sont effectués avec l'identité de sécurité que vous avez utilisée pour vous connecter au servlet. Cette identité est communément nommée identité de l'appelant. Toutefois, une autre solution consiste à déléguer les appels à une autre identité en utilisant la spécification RunAs, pour que les appels suivants effectués par le servlet soient exécutés sous cette autre identité. En résumé, vous disposez de deux options pour propager l'identité de sécurité :
  • Propager l'identité de l'appelant tout au long de la chaîne d'appels (il s'agit du comportement par défaut).
  • Déléguer à l'identité RunAs que vous pouvez spécifier en utilisant la spécification RunAs.

Une fois que le serveur a authentifié l'utilisateur d'origine, il authentifie l'utilisateur RunAs. Si cette authentification échoue, le serveur revient au mécanisme de propagation de l'identité de l'appelant.

Pour pouvoir utiliser la spécification RunAs, vous devez mettre à jour le descripteur de déploiement de votre application afin d'y inclure l'élément run-as ou l'annotation @RunAs. Associez cet élément au rôle de sécurité auquel vous souhaitez déléguer.

Voir Configuration de l'authentification RunAs dans le profil Liberty.

Module de connexion par proxy

La classe du module de connexion par proxy charge le module de connexion du serveur d'applications et délègue toutes les opérations à la véritable implémentation de module de connexion. Cette implémentation est spécifiée comme délégué dans la configuration des options. Le module de connexion par proxy est nécessaire car les chargeurs de classe des applications ne voient pas les chargeurs de classe des bibliothèques partagées du produit de serveur d'applications. Dans le cadre du développement de modules de connexion de programmation pour JAAS qui utilise la méthode Login() de la classe LoginContext, avec WSLogin comme entrée de contexte de connexion JAAS, le module de connexion proxy délègue tout le traitement à l'entrée de contexte de connexion JAAS system.DEFAULT.

Connexion par certificat

La fonction de connexion par certificat permet d'authentifier les demandes Web telles que celles des servlets en utilisant des certificats X509 côté client au lieu de fournir un ID utilisateur et un mot de passe.

L'authentification par certificat fonctionne en associant un utilisateur issu du registre d'utilisateurs au nom distinctif (DN) figurant dans le certificat client d'une demande Web. La confiance est établie en faisant reconnaître au serveur l'authenticité du certificat du client (par exemple, le signataire du certificat du client doit être dans le fichier de clés certifiées du serveur). Ce mécanisme évite aux utilisateurs de fournir un mot de passe pour être reconnus par le serveur.

Voir Sécurisation des communications avec le profil Liberty.

Module de connexion par table de hachage

Recherchez les attributs requis dans le registre d'utilisateurs, placez-les dans une table de hachage, puis ajoutez cette dernière à l'état partagé. Si l'identité change dans ce module de connexion, vous devez ajouter la table de hachage à l'état partagé. Si l'identité ne change pas, mais que la valeur de requiresLogin est true, vous pouvez créer la table de hachage des attributs. Théoriquement, rien ne vous oblige à créer une table de hachage dans cette situation, car le profil Liberty se charge de la connexion pour vous. Sa création est toutefois à envisager dans certains cas pour rassembler les attributs. Par exemple, si vous utilisez votre propre registre d'utilisateurs spécial, la solution la plus simple est certainement de créer une implémentation de UserRegistry, d'utiliser une table de hachage et de laisser le serveur collecter pour vous les attributs de l'utilisateur.

Les règles ci-après définissent plus en détail la connexion par table de hachage. Vous devez utiliser un objet java.util.Hashtable soit dans le sujet (données d'identification publiques ou privées), soit dans la mappe de hachage qui contient l'état partagé. La classe com.ibm.wsspi.security.token.AttributeNameConstants définit les clés qui contiennent les informations de l'utilisateur. Si l'objet Hashtable est inséré dans l'état partagé du contexte de connexion en utilisant un module de connexion personnalisé qui est listé avant le module de connexion avec table de hachage, la valeur de l'objet java.util.Hashtable est recherchée au moyen de la clé suivante dans la mappe de hachage de l'état partagé :

Propriété
com.ibm.wsspi.security.cred.propertiesObject
Référence à la propriété
AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
Explication
Cette clé recherche l'objet Hashtable qui contient les propriétés requises dans l'état partagé du contexte de connexion.
Résultat prévu
Un objet java.util.Hashtable.

Si un objet java.util.Hashtable est trouvé à l'intérieur du sujet ou dans la zone d'état partagé, vérifiez que la table de hachage contient les propriétés suivantes :

  • com.ibm.wsspi.security.cred.uniqueId
    Référence à la propriété
    AttributeNameConstants.WSCREDENTIAL_UNIQUEID
    Retours
    java.util.String
    Explication
    La valeur de la propriété doit être une représentation unique de l'utilisateur. Pour l'implémentation par défaut du profil Liberty, cette propriété représente les informations qui sont stockées dans la configuration d'autorisations de l'application. Ces informations figurent dans le descripteur de déploiement de l'application une fois que celle-ci a été déployée et que le mappage entre utilisateurs et rôles a été effectué. Reportez-vous aux exemples de formats attendus si le mappage des utilisateurs et des rôles est effectué via la recherche dans une implémentation de registre d'utilisateurs dans le profil Liberty.
    Exemples de formats requis
    Tableau 1. Exemples de formats pour UniqueUserId. Ce tableau fournit des exemples de formats attendus.
    Registre d'utilisateurs Valeur de format (UniqueUserId)
    LDAP ldapRegistryRealm/cn=kevin,o=mycompany,c=use
    De base basicRegistryRealm/kelvin
    La propriété com.ibm.wsspi.security.cred.uniqueId est requise.
  • com.ibm.wsspi.security.cred.securityName
    Référence à la propriété
    AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
    Retours
    java.util.String
    Explication
    Cette propriété recherche le paramètre securityName de l'utilisateur à authentifier. Ce nom est communément appelé nom d'affichage ou nom abrégé. Le profil Liberty utilise l'attribut securityName pour les interfaces de programme d'application (API) getRemoteUser, getUserPrincipal et getCallerPrincipal. Pour garantir la compatibilité des valeurs de securityName avec le format utilisé dans l'implémentation par défaut, appelez la méthode public String getUserSecurityName(String uniqueUserId) dans l'implémentation de UserRegistry.
    Exemples de formats requis
    Tableau 2. Exemples de formats pour securityName. Ce tableau fournit des exemples de formats attendus.
    Registre d'utilisateurs Valeur de format (securityName)
    LDAP kevin
    De base kevin
    La propriété com.ibm.wsspi.security.cred.securityname est requise.
  • com.ibm.wsspi.security.cred.group
    Référence à la propriété
    AttributeNameConstants. WSCREDENTIAL_GROUP
    Retours
    java.util.ArrayList
    Explication
    Cette clé recherche les groupes auxquels l'utilisateur appartient (le résultat est retourné dans un objet ArrayList). Les groupes sont spécifiés au format nom_domaine/nom_utilisateur. Ce format est important car les groupes sont utilisés par le moteur d'autorisations du profil Liberty pour les mappages groupe-vers-rôle dans le descripteur de déploiement. Le format fourni doit correspondre à celui qui est attendu par l'implémentation par défaut du profil Liberty. Lorsque vous utilisez un fournisseur d'autorisations tiers, vous devez utiliser le format attendu par ce dernier. Pour garantir la compatibilité des ID de groupe uniques avec le format utilisé dans l'implémentation par défaut, appelez la méthode public List getUniqueGroupIds(String uniqueUserId) dans l'implémentation de UserRegistry.
    Exemples de formats requis
    Tableau 3. Exemples de formats pour group. Ce tableau contient des exemples de formats pour la configuration du mappage des identités entrantes.
    Registre d'utilisateurs Valeur de format (groupe)
    LDAP ldapRegistryRealm/cn=group1,o=Groups,c=US
    De base basicRegistryRealm/group1
    La propriété com.ibm.wsspi.security.cred.group est requise. Les utilisateurs ne sont pas obligés d'être associés à des groupes.
  • com.ibm.wsspi.security.cred.cacheKey
    Référence à la propriété
    AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
    Retours
    java.lang.Object
    Explication
    Cette propriété de clé peut spécifier un objet qui représente les propriétés uniques de la connexion, y compris les informations propres à l'utilisateur et des attributs dynamiques susceptibles d'affecter l'unicité. Par exemple, lorsque l'utilisateur se connecte à partir d'un emplacement A, ce qui peut avoir une incidence sur le contrôle d'accès, la clé de cache doit inclure l'emplacement A pour que le sujet reçu soit le sujet correct pour l'emplacement en cours.
    La propriété com.ibm.wsspi.security.cred.cacheKey n'est pas obligatoire. Lorsqu'elle n'est pas spécifiée, la valeur de la recherche de cache est celle spécifiée pour WSCREDENTIAL_UNIQUEID. Lorsque ces informations se trouvent dans l'objet java.util.Hashtable, le profil Liberty crée un sujet similaire au sujet qui passe par le processus de connexion normal, au moins pour LTPA. Le nouveau sujet contient un objet WSCredential et un objet WSPrincipal, tous deux entièrement renseignés avec les informations trouvées dans l'objet Hashtable.

Icône indiquant le type de rubrique Rubrique de concept

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=cwlp_authentication
Nom du fichier : cwlp_authentication.html