Connexions accréditées avec DB2
Les connexions accréditées permettent au serveur d'applications d'utiliser les objets DB2 Trusted Context afin d'établir des connexions à un utilisateur dont les données d'identification sont accréditées par le serveur DB2 pour ouvrir la connexion. En établissant un contexte accrédité, l'utilisateur est autorisé à confirmer l'identité d'autres utilisateurs sur le serveur DB2 sans qu'ils n'aient à s'authentifier de nouveau. Ainsi, il est possible d'améliorer la sécurité de votre base de données DB2 en supprimant le besoin d'attribuer tous les privilèges à un seul utilisateur. L'implémentation de connexions accréditées a pour conséquence la propagation de l'identité client ainsi que l'optimisation du regroupement de connexions afin de supprimer la baisse des performances due à la fermeture et à la réouverture des connexions avec une identité différente.
Pour réduire le coût lié à l'établissement de nouvelles connexions, le gestionnaire de connexions conserve un pool de connexions dans lequel chaque connexion est suivie par les justificatifs utilisés pour l'ouverture de la connexion. Lorsqu'une application a besoin d'une connexion, le gestionnaire de connexions utilise les données d'identification pour la correspondance d'une connexion disponible à partir du pool de connexions. Si aucune connexion n'est disponible et que le nombre maximal de connexions n'a pas été atteint, le gestionnaire de pools de connexions ouvre une nouvelle connexion à l'aide de ces justificatifs. Ce mappage de connexion est le mappage de connexion par défaut utilisé par le serveur d'applications et est connu sous le nom de mappage de justificatifs "plusieurs à un" car la connexion est ouverte à l'aide des justificatifs, qui sont généralement différents de l'identité RunAs. Ce mappage prend en charge le regroupement de connexions simple mais l'identité de l'appelant n'est jamais propagée au serveur de base de données.
Pour propager l'identité de l'appelant au serveur de base de données vous pouvez connecter un module de connexion JAAS (Java™ Authentication and Authorization Service). A l'aide de cette méthode, vous mappez les justificatifs du serveur d'applications vers les justificatifs d'utilisateur appropriés pour le domaine de sécurité du serveur de base de données. Cette approche conserve l'identité de l'appelant mais n'optimise pas le regroupement de connexions.
Les connexions accréditées sont utilisées à la place du mappage par défaut ou d'un mappage JAAS pour établir une connexion à la source de données. Les connexions accréditées prennent en charge la propagation de l'identité client et peuvent également utiliser le regroupement de connexions pour réduire la baisse des performances due à la fermeture et à la réouverture des connexions avec une identité différente. Les connexions accréditées utilisent l'objet de contexte accrédité DB2.
![[z/OS]](../images/ngzos.gif)
L'utilisation de la connexion accréditée fournit les points de plug-in nécessaires pour permettre l'ajout de votre propre implémentation sécurisée du contexte DB2 accrédité. Les connexions accréditées séparent l'identité utilisée pour établir la connexion à partir de l'identité qui accède aux services du serveur dorsal. La connexion est établie par un utilisateur dont les justificatifs sont approuvés par le serveur DB2 afin d'ouvrir la connexion. Le même utilisateur est également accrédité pour vérifier l'identité des autres utilisateurs. Cette vérification permet de renforcer la sécurité de la base de données en supprimant le besoin d'accorder tous les droits à un seul utilisateur.
Lorsque l'application demande une connexion à la base de données, le gestionnaire de bases de données peut trouver toute connexion accréditée inactive et vérifier l'identité de l'utilisateur sur le serveur dorsal. Toutes les opérations effectuées sur le serveur dorsal proviennent de l'identité de l'utilisateur vérifié. L'utilisation d'un mappage utilisateur peut toujours être nécessaire si le serveur dorsal utilise un autre référentiel d'utilisateurs que celui du serveur d'applications.
- Un objet principal de ressource représenté par ce sujet de ressource
- Un objet PasswordCredential dans l'ensemble de données d'identification privées
- Un objet IdentityPrincipal dans l'ensemble de principaux