A trusted context is a database object that defines a trust
relationship for a connection between the database and an external
entity such as an application server.
The trust relationship is based upon the following set of attributes:
- System authorization ID: Represents the user that establishes
a database connection
- IP address (or domain name): Represents the host from which a
database connection is established
- Data stream encryption: Represents the encryption setting (if
any) for the data communication between the database server and the
database client
When a user establishes a database connection, the DB2® database system checks whether the connection
matches the definition of a trusted context object in the database.
When a match occurs, the database connection is said to be trusted.
A trusted connection cannot be established if the connection
is to a local database using inter-process communication (IPC).
A trusted connection allows the initiator of this trusted connection
to acquire additional capabilities that may not be available outside
the scope of the trusted connection. The additional capabilities vary
depending on whether the trusted connection is explicit or implicit.
The initiator of an explicit trusted connection has the ability
to:
- Switch the current user ID on the connection to a different user
ID with or without authentication
- Acquire additional privileges via the role inheritance feature
of trusted contexts
An implicit trusted connection is a trusted connection that is
not explicitly requested; the implicit trusted connection results
from a normal connection request rather than an explicit trusted connection
request. No application code changes are needed to obtain an implicit
connection. Also, whether you obtain an implicit trusted connection
or not has no effect on the connect return code (when you request
an explicit trusted connection, the connect return code indicates
whether the request succeeds or not). The initiator of an implicit
trusted connection can only acquire additional privileges via the
role inheritance feature of trusted contexts; they cannot switch the
user ID.
How using trusted contexts enhances security
The
three-tiered application model extends the standard two-tiered client
and server model by placing a middle tier between the client application
and the database server. It has gained great popularity in recent
years particularly with the emergence of web-based technologies and
the Java™ 2 Enterprise Edition
(J2EE) platform. An example of a software product that supports the
three-tier application model is IBM® WebSphere® Application Server
(WAS).
In a three-tiered application model, the middle tier
is responsible for authenticating the users running the client applications
and for managing the interactions with the database server. Traditionally,
all the interactions with the database server occur through a database
connection established by the middle tier using a combination of a
user ID and a credential that identify that middle tier to the database
server. This means that the database server uses the database privileges
associated with the middle tier's user ID for all authorization checking
and auditing that must occur for any database access, including access
performed by the middle tier on behalf of a user.
While the
three-tiered application model has many benefits, having all interactions
with the database server (for example, a user request) occur under
the middle tier's authorization ID raises several security concerns,
which can be summarized as follows:
- Loss of user identity
Some enterprises prefer to know the identity
of the actual user accessing the database for access control purposes.
- Diminished user accountability
Accountability through auditing
is a basic principle in database security. Not knowing the user's
identity makes it difficult to distinguish the transactions performed
by the middle tier for its own purpose from those performed by the
middle tier on behalf of a user.
- Over granting of privileges to the middle tier's authorization
ID
The middle tier's authorization ID must have all the privileges
necessary to execute all the requests from all the users. This has
the security issue of enabling users who do not need access to certain
information to obtain access anyway.
- Weakened security
In addition to the privilege issue raised
in the previous point, the current approach requires that the authorization
ID used by the middle tier to connect must be granted privileges on
all resources that might be accessed by user requests. If that middle-tier
authorization ID is ever compromised, then all those resources will
be exposed.
- "Spill over" between users of the same connection
Changes by
a previous user can affect the current user.
Clearly, there is a need for a mechanism whereby the actual user's
identity and database privileges are used for database requests performed
by the middle tier on behalf of that user. The most straightforward
approach of achieving this goal would be for the middle-tier to establish
a new connection using the user's ID and password, and then direct
the user's requests through that connection. Although simple, this
approach suffers from several drawbacks which include the following:
- Inapplicability for certain middle tiers. Many middle-tier servers
do not have the user authentication credentials needed to establish
a connection.
- Performance overhead. There is an obvious performance overhead
associated with creating a new physical connection and re-authenticating
the user at the database server.
- Maintenance overhead. In situations where you are not using a
centralized security set up or are not using single sign-on, there
is maintenance overhead in having two user definitions (one on the
middle tier and one at the server). This requires changing passwords
at different places.
The trusted contexts capability addresses this problem. The security
administrator can create a trusted context object in the database
that defines a trust relationship between the database and the middle-tier.
The middle-tier can then establish an explicit trusted connection
to the database, which gives the middle tier the ability to switch
the current user ID on the connection to a different user ID, with
or without authentication. In addition to solving the end-user identity
assertion problem, trusted contexts offer another advantage. This
is the ability to control when a privilege is made available to a
database user. The lack of control on when privileges are available
to a user can weaken overall security. For example, privileges may
be used for purposes other than they were originally intended. The
security administrator can assign one or more privileges to a role
and assign that role to a trusted context object. Only trusted database
connections (explicit or implicit) that match the definition of that
trusted context can take advantage of the privileges associated with
that role.
Enhancing performance
When you use trusted
connections, you can maximize performance because of the following
advantages:
- No new connection is established when the current user ID of the
connection is switched.
- If the trusted context definition does not require authentication
of the user ID to switch to, then the overhead associated with authenticating
a new user at the database server is not incurred.
Example of creating a trusted context
Suppose
that the security administrator creates the following trusted context
object:
CREATE TRUSTED CONTEXT CTX1
BASED UPON CONNECTION USING SYSTEM AUTHID USER2
ATTRIBUTES (ADDRESS '192.0.2.1')
DEFAULT ROLE managerRole
ENABLE
If user
user1 requests a trusted connection
from IP address 192.0.2.1, the DB2 database
system returns a warning (SQLSTATE 01679, SQLCODE +20360) to indicate
that a trusted connection could not be established, and that user
user1 simply
got a non-trusted connection. However, if user
user2 requests
a trusted connection from IP address 192.0.2.1, the request is honored
because the connection attributes are satisfied by the trusted context
CTX1. Now that use
user2 has established a trusted connection,
he or she can now acquire all the privileges and authorities associated
with the trusted context role managerRole. These privileges and authorities
may not be available to user
user2 outside the scope of this
trusted connection