L'introduction de la prise en charge de plusieurs bases de données de sécurité dans Firebird a entraîné de nouveaux problèmes qui ne pouvaient pas se produire avec une seule base de données de sécurité globale. Les grappes de bases de données utilisant la même base de données de sécurité ont été séparées de manière efficace. Les mappings permettent d'obtenir la même efficacité lorsque plusieurs bases de données utilisent leur propre base de données de sécurité. Dans certains cas, la gestion est nécessaire pour limiter la communication entre ces clusters. Par exemple :
lorsque
EXECUTE STATEMENT ON EXTERNAL DATA SOURCEnécessite un échange de données entre clusters ;lorsque l'accès à la base de données
SYSDBAà l'échelle du serveur est requis depuis d'autres clusters utilisant des services ;Des problèmes similaires existaient dans Firebird 2.1 et 2.5 sous Windows, en raison de la prise en charge de l'authentification de confiance : il y avait deux listes d'utilisateurs distinctes, une dans la base de données de sécurité, et une dans Windows, dans les cas où elles devaient être liées. Par exemple, le rôle accordé à un groupe Windows est automatiquement attribué aux membres de ce groupe.
La solution unique pour tous ces cas est de créer des règles pour faire correspondre les informations de l'utilisateur connecté aux objets de sécurité internes CURRENT_USER et CURRENT_ROLE.
Note | Firebird a une règle par défaut globale intégrée : les utilisateurs qui passent les contrôles de la base de données de sécurité sont toujours mappés à n'importe quelle base de données un à un. C'est une règle sûre : il n'est pas logique que la base de données de sécurité ne se fasse pas confiance. |