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.

Restriction : Pour utiliser la fonctionnalité de connexion accréditée vous devez utiliser DB2 Database for Linux, UNIX et Windows Version 9.5 ou version suivante ou DB2 Database Version 9.1 for z/OS ou version suivante. Vous pouvez utiliser les connexions accréditées si la version 7.0 est installée sur un système iSeries tant qu'une version prise en charge de DB2 est installée sur une plateforme autre qu'un système iSeries et que le pilote universel DB2 est utilisé. Consultez la liste des logiciels pris en charge par le serveur d'applications pour plus d'informations relatives à la prise en charge.

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.

Le contexte DB2 accrédité est un objet qui est défini par l'administrateur de la base de données et qui contient un ID d'autorisation système et un jeu d'attributs d'accréditation. Les attributs de sécurisation identifient les caractéristiques d'une connexion requises pour que la connexion soit considérée comme digne de confiance. La relation entre une connexion à une base de données et un contexte accrédité est établie lorsque la connexion au serveur DB2 est créée. Après avoir défini le contexte accrédité et établi une connexion accréditée initiale au serveur de base de données DB2 le serveur d'applications peut utiliser cette connexion de base de données pour un utilisateur différent sans sa réauthentification complète. Cette situation est due au fait qu'un jeton d'authentification est requis avec l'identité utilisateur. La base de données authentifie l'utilisateur final puis vérifie ensuite l'autorisation utilisateur pour accéder à la base de données avant de permettre que des demandes de base de données soient traitées au nom de cet utilisateur.
[z/OS]Restriction : Pour un serveur z/OS, l'identité de l'utilisateur doit être l'ID RACF (Resource Access Control Facility).(RACF).

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.

Une nouvelle configuration de mappage appelée TrustedConnectionMapping implémente les connexions accréditées. La configuration TrustedConnectionMapping mappe le sujet RunAs vers un objet de ressource qui contient les éléments suivants :
  • 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
L'objet principal représente l'identité RunAs. L'objet PasswordCredential contient un ID utilisateur et un mot de passe à utiliser par l'adaptateur de ressources pour établir la connexion accréditée. L'objet IdentityPrincipal par défaut contient l'identité RunAs mais peut être modifié pour utiliser l'identité de l'appelant. L'objet IdentityPrincipal contient également une identité d'utilisateur d'origine qui représente l'utilisateur qui a envoyé la demande, un nom de domaine facultatif qui indique l'ensemble de registres dans lequel l'identité de l'utilisateur est définie et un jeton de sécurité facultatif qui est un contexte de sécurité sérialisé de l'utilisateur.

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_trustedconnections
Nom du fichier : csec_trustedconnections.html