Benefits of federated trusted connections

In a multi-tier application model, federated trusted connections reuse a single physical connection to propagate each user's real identity through the tiers to the database server.

To understand the benefits of federated trusted connections, consider the problems inherent in a typical multi-tier application model. A multi-tier application model consists enterprise users (Tier 1) who interact with an application that runs on an application server (Tier 2), which routes all database access through the federated server (Tier 3), which manages the communications with various database servers (Tier 4). In this model, the application server authenticates users and manages interactions with the federated server. The federated server translates user requests into data-source specific formats, establishes connections with the remote data sources, and sends requests to them.

This model uses the application server ID and password to create a connection to the database server; the federated server merely passes the ID and password from the application server to the database server. The database server uses the database privileges that are associated with this ID to authorize and audit all transactions that the application server performs, including all transactions that the application server performs on the behalf of enterprise users.

Using the application server ID presents these problems:

The real identity of the user who performs a transaction is unknown because the application server performs all transactions.
Users cannot be held accountable for transactions because they cannot be audited.
The principle of least privilege is violated because the application server ID requires the superset of all privileges that all users require.
Data is vulnerable if the application server ID is compromised.

Federated trusted connections address these problems and provide these benefits that can enhance the security and performance of the system:

User identity is known: Because users are switched on the connection, you know the actual identity of the users who access the database.

Users are held accountable: The audit logs for the federated database and for the remote data source database identify the transactions that the application server performs for its own purposes and the transactions that individual users perform. Therefore, you can hold specific users accountable for specific transactions.

Privileges are limited: When you create a trusted context, you can grant a default database role to all users and can grant specific roles to specific users. Only trusted database connections that match the definition of that trusted context can take advantage of the privileges that are associated with that role.

Data is less vulnerable: In a system that uses federated trusted connections, the application server ID does not require the superset of all privileges that all users need. Therefore, if the application server ID is ever compromised, data is less vulnerable than it is when the ID has the superset of all of the privileges that all users require.

Administrative maintenance is minimized: The need to create and maintain user mappings is significantly reduced.

Performance is improved: After an explicit trusted connection is established, the federated server can switch the current user ID on the connection to a different user ID, with or without requiring that the user authenticate. The reuse of the same physical connection for different users can improve performance.