• when EXECUTE STATEMENT ON EXTERNAL DATA SOURCE requires some data exchange between clusters

    • when server-wide SYSDBA access to databases is needed from other clusters, using services.

    • comparable problems that have existed on Firebird 2.1 and 2.5 for Windows, due to support for Trusted User authentication: two separate lists of users — one in the security database and another in Windows, with cases where it was necessary to relate them. An example is the demand for a ROLE granted to a Windows group to be assigned automatically to members of that group.

    The single solution for all such cases is mapping the login information assigned to a user when it connects to a Firebird server to internal security objects in a database — CURRENT_USER and CURRENT_ROLE.

    The mapping rule consists of four pieces of information:

    1. mapping scope — whether the mapping is local to the current database or whether its effect is to be global, affecting all databases in the cluster, including security databases

    2. mapping name — an SQL identifier, since mappings are objects in a database, like any other

    3. the object FROM which the mapping maps. It consists of four items:

      • The authentication source

        • plugin name or

        • the product of a mapping in another database or

        • use of server-wide authentication or

        • any method

      • The name of the database where authentication succeeded

      • The name of the object from which mapping is performed

      • The type of that name — username, role, or OS group — depending upon the plugin that added that name during authentication.

        Any item is accepted but only type is required.

    Used forCreating a mapping of a security object

    Available inDSQL

    Syntax

    Table 13.7.2.1 CREATE MAPPING Statement Parameter

    The CREATE MAPPING statement creates a mapping of security objects (e.g. users, groups, roles) of one or more authentication plugins to internal security objects - CURRENT_USER and CURRENT_ROLE.

    If the GLOBAL clause is present, then the mapping will be applied not only for the current database, but for all databases in the same cluster, including security databases.

    Warning

    There can be global and local mappings with the same name. They are distinct objects.

    Note

    Global mapping works best if a Firebird 3.0 or higher version database is used as the security database. If you plan to use another database for this purpose — using your own provider, for example — then you should create a table in it named RDB$MAP, with the same structure as RDB$MAP in a Firebird 3.0 or higher database and with SYSDBA-only write access.

    The USING clause describes the mapping source. It has a very complex set of options:

    • an explicit plugin name (PLUGIN *plugin_name*) means it applies only for that plugin

    • it can use any available plugin (ANY PLUGIN); although not if the source is the product of a previous mapping

    • it can be made to work only with server-wide plugins (SERVERWIDE)

    • it can be made to work only with previous mapping results (MAPPING)

    • you can omit to use of a specific method by using the asterisk () argument

    • it can specify the name of the database that defined the mapping for the FROM object (IN *database*)

      Note

      This argument is not valid for mapping server-wide authentication.

    The FROM clause describes the object to map. The FROM clause has a mandatory argument, the type of the object named. It has the following options:

    • When mapping names from plugins, type is defined by the plugin

    • When mapping the product of a previous mapping, type can be only USER or ROLE

    • If an explicit from_name is provided, it will be taken into account by this mapping

    • Use the ANY keyword to work with any name of the given type.

    The TO clause specifies the user or role that is the result of the mapping. The to_name is optional. If it is not specified, then the original name of the mapped object will be used.

    For roles, the role defined by a mapping rule is only applied when the user does not explicitly specify a role on connect. The mapped role can be assumed later in the session using , even when the mapped role is not explicitly granted to the user.

    13.7.2.1 Who Can Create a Mapping

    The CREATE MAPPING statement can be executed by:

    • The database owner — if the mapping is local

    13.7.2.2 CREATE MAPPING examples

    1. Enable use of Windows trusted authentication in all databases that use the current security database:

      1. CREATE GLOBAL MAPPING TRUSTED_AUTH
      2. USING PLUGIN WIN_SSPI
      3. FROM ANY USER
      4. TO USER;
    2. Enable RDB$ADMIN access for windows admins in the current database:

      1. CREATE MAPPING WIN_ADMINS
      2. USING PLUGIN WIN_SSPI
      3. FROM Predefined_Group
      4. DOMAIN_ANY_RID_ADMINS
      5. TO ROLE RDB$ADMIN;

      Note

      The group DOMAIN_ANY_RID_ADMINS does not exist in Windows, but such a name would be added by the Win_Sspi plugin to provide exact backwards compatibility.

    3. Enable a particular user from another database to access the current database with another name:

      1. USING PLUGIN SRP IN "rt"
      2. FROM USER U1 TO USER U2;

      Important

      Database names or aliases will need to be enclosed in double quotes on operating systems that have case-sensitive file names.

    4. Enable the server’s SYSDBA (from the main security database) to access the current database. (Assume that the database is using a non-default security database):

      1. CREATE MAPPING LEGACY_2_GUEST
      2. USING PLUGIN legacy_auth
      3. FROM ANY USER

    See also, Section 13.7.4, CREATE OR ALTER MAPPING,

    Used forAltering a mapping of a security object

    Available inDSQL

    Syntax

    1. ALTER [GLOBAL] MAPPING name
    2. USING
    3. { PLUGIN plugin_name [IN database]
    4. | ANY PLUGIN [IN database | SERVERWIDE]
    5. | MAPPING [IN database] | '*' [IN database] }
    6. FROM {ANY type | type from_name}
    7. TO {USER | ROLE} [to_name]

    For details on the options, see Section 13.7.2, CREATE MAPPING.

    The ALTER MAPPING statement allows you to modify any of the existing mapping options, but a local mapping cannot be changed to GLOBAL or vice versa.

    Important

    Global and local mappings of the same name are different objects.

    13.7.3.1 Who Can Alter a Mapping

    The ALTER MAPPING statement can be executed by:

    13.7.3.2 ALTER MAPPING examples

    Alter mapping

    1. ALTER MAPPING FROM_RT
    2. USING PLUGIN SRP IN "rt"
    3. FROM USER U1 TO USER U3;

    See alsoSection 13.7.2, CREATE MAPPING, , Section 13.7.5, DROP MAPPING

    Used forCreating a new or altering an existing mapping of a security object

    Available inDSQL

    Syntax

    For details on the options, see .

    The CREATE OR ALTER MAPPING statement creates a new or modifies an existing mapping.

    Important

    Global and local mappings of the same name are different objects.

    13.7.4.1 CREATE OR ALTER MAPPING examples

    Creating or altering a mapping

    1. CREATE OR ALTER MAPPING FROM_RT
    2. USING PLUGIN SRP IN "rt"
    3. FROM USER U1 TO USER U4;

    See also, Section 13.7.3, ALTER MAPPING,

    Used forDropping (removing) a mapping of a security object

    Available inDSQL

    Syntax

    1. DROP [GLOBAL] MAPPING name

    Table 13.7.5.1 DROP MAPPING Statement Parameter

    ParameterDescription

    name

    Mapping name

    The DROP MAPPING statement removes an existing mapping. If GLOBAL is specified, then a global mapping will be removed.

    Important

    Global and local mappings of the same name are different objects.

    13.7.5.1 Who Can Drop a Mapping

    The DROP MAPPING statement can be executed by:

    • The database owner — if the mapping is local

    13.7.5.2 examples

      See also