Public user mappings

To ensure the security of your federated server there are restrictions for using public user mappings to access your data sources.

For all data sources in Federation component, you can create public user mappings to map all local database users to a single authorization ID and password. To ensure the security of your federated server while using a public user mapping, the following restrictions exist:

Public user mappings and non-public user mappings cannot coexist for the same server definition

For a given server definition, only one type of user mapping is allowed, either public or non-public user mappings. If one type of user mapping exists for the server, you receive error SQL1515N if you attempt to create a user mapping of the other type. For example, if a public user mapping has been defined for a server, you cannot create non-public user mappings for the same server. The reverse is also true. If non-public user mappings exist for a server definition, you receive error SQL1515N if you attempt to create a public user mapping for that server.

Restricting the coexistence of public and non-public user mappings also restricts the use of outbound federated trusted connections. If the FED_PROXY_USER server option exists for a server definition, you receive error SQL1515N if you attempt to create a public user mapping. You also receive error SQL1516N if you attempt to run the ALTER SERVER statement to add the FED_PROXY_USER server option when a public user mapping exists.

Public user mappings are not retrieved from an external user mapping repository

You are not restricted from attempting to create public user mappings on external user mapping repositories but the federated server does not search or retrieve them to ensure your security.