FirebirdSQL logo
 Les opérateurs peuvent révoquer des privilèges et des rôlesCryptage des bases de données 

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 SOURCE né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.

CREATE MAPPING

Destination

Création d’un mapping de l’objet de sécurité.

Disponible en

DSQL

Syntaxe
CREATE [GLOBAL] MAPPING name
  USING {
      PLUGIN plugin_name [IN database]
    | ANY PLUGIN [IN database | SERVERWIDE]
    | MAPPING [IN database]
    | '*' [IN database] }
  FROM { ANY type | type from_name }
  TO { USER | ROLE } [to_name]
Table 1. Paramètre de la clause CREATE MAPPING
Paramètre Description

name

Nom d’affichage. Peut contenir jusqu’à 63 caractères.

plugin_name

Le nom du plug-in d’authentification.

database

Le nom de la base de données dans laquelle l’authentification a eu lieu.

type

Le type d’objet à afficher.

from_name

Le nom de l’objet à afficher.

to_name

Le nom de l’objet (utilisateurs ou rôles) à mettre en correspondance.

L’instruction CREATE MAPPING crée un mapping des objets de sécurité (utilisateurs, groupes, rôles) d’un ou plusieurs plugins d’authentification vers les objets de sécurité internes - CURRENT_USER et CURRENT_ROLE. Le nom du mapping doit être unique parmi les noms de mapping.

Si l’option GLOBAL est présente, le mappage sera appliqué non seulement à la base de données actuelle, mais à toutes les bases de données du même cluster, y compris la base de données de sécurité.

Important

Si des mappings globaux et locaux portent le même nom, vous devez savoir qu’il s’agit d’objets différents.
Note

Le mappage global fonctionne si vous utilisez une base de données Firebird 3 ou supérieure comme base de données de sécurité. Si vous prévoyez d’utiliser une autre base de données, par exemple pour utiliser votre propre fournisseur, vous devez créer une table dans celle-ci et la nommer RDB$MAP avec la même structure que RDB$MAP dans la base de données Firebird 3 et donner un accès en écriture uniquement à SYSDBA.

La clause USING décrit la source du mapping.Il dispose d’un ensemble très complexe d’options :

  • spécifier explicitement un nom de plugin (option PLUGIN plugin_name) signifie que cela ne fonctionnera qu’avec ce plugin ;

  • il peut utiliser n’importe quel plugin disponible (option ANY PLUGIN), même si la source est le produit d’un mapping précédent ;

  • Il est possible de faire en sorte qu’il ne fonctionne qu’avec des plugins à l’échelle du serveur (l’option SERVERWIDE) ;

  • On peut faire en sorte qu’il ne fonctionne qu’avec les résultats de la cartographie précédente (l’option MAPPING) ;

  • Vous pouvez omettre l’utilisation de l’une des méthodes en utilisant un astérisque (*) comme argument ;

  • il peut contenir le nom de la base de données (option IN) à partir de laquelle l’objet FROM est mappé.

    Note

    Cet argument n’est pas valable pour le mappage avec une authentification à l’échelle du serveur.

La clause FROM décrit l’objet affiché.Il prend un argument obligatoire — le type d’objet.

Caractéristiques :

  • lors de l’affichage de noms provenant de plugins, le type est défini par le plugin ;

  • lors de l’affichage d’un produit de mapping précédent, le type ne peut être que USER et ROLE ;

  • si le nom de l’objet est spécifié explicitement, il sera pris en compte dans l’affichage ;

  • Si le mot clé "ANY" est utilisé, les objets de ce type, quel que soit leur nom, seront affichés.

La combinaison de la source (phrase USING) et de l’objet de mapping (phrase FROM) doit être unique, sinon une erreur sera générée.Cela n’est autorisé que si un mappage est global et l’autre local.

La phrase TO spécifie l’utilisateur ou le rôle auquel le mapping sera associé.to_name est un argument facultatif.S’il n’est pas spécifié, le nom original de l’objet mappé sera utilisé comme nom d’objet.

Note

Le mappage local remplace le mappage global avec la même combinaison de source et d’objet de mappage. Cela fonctionne à peu près de la même manière avec les paramètres : les paramètres au niveau de la base de données (databases.conf) remplacent les paramètres globaux (firebird.conf).