End-to-end federated trusted contexts in WebSphere Federation Server V9.5

End-to-end identity assertion in multi-tier systems involving WebSphere Federation Server V9.5

End-to-end federated trusted contexts is a new feature set to debut in IBM® WebSphere® Federation Server V9.5. This feature alleviates the security concerns associated with multi-tier models by propagating end-user identities through all tiers of the application model without sacrificing overall performance. This article describes the scenario and benefit of end-to-end federated trusted contexts, together with step-by-step configuration and tips.

Priya Baliga, Staff Software Engineer, IBM

Priya Baliga Priya Baliga is a software engineer in the Information Server Data Virtualization team at the Silicon Valley Laboratory in San Jose, California. Priya was the development lead for the federated trusted contexts feature. Priya joined IBM in 2004 after completing her Masters in Computer Science. She has publications and pending patents in the federation and security areas.



Eileen Lin (etlin@us.ibm.com), Senior Technical Staff Member, IBM

Eileen LinDr. Eileen Lin is a senior technical staff member in Silicon Valley Laboratory in San Jose, Calif. She is one of the original members responsible for the success of DataJoiner, a federated database product that is the predecessor of the federation technology in DB2. Currently, she is the architect for the data federation technology in WebSphere Federation Server. Dr. Lin has many patents covering areas such as federation technology, query optimization, and parallel query processing.



13 December 2007

Introduction

Modern enterprise applications are increasingly adopting multi-tier application models wherein user requests are routed from the database client to the database server through multiple middleware layers. Some examples of common middle tiers include application servers (for hosting applications) and federation servers (for transparent access to heterogeneous data sources). Traditionally, your federated multi-tier enterprise application has to make a choice between security and performance. But this will all change with the introduction of federated trusted contexts in WebSphere Federation Server V9.5, which exploits the trusted context feature built into the federation server and the data sources. As a result, you can achieve end-to-end identity assertion in a trusted environment with or without re-authentication.

There are two ways to leverage this feature:

  1. End-to-end federated trusted contexts offer identity assertion through all layers of a multi-tier application model involving WebSphere Federation Server.
  2. Outbound federated trusted contexts enable elimination of most user mappings, thereby easing the administration pain associated with dual maintenance of passwords in WebSphere Federation Server and at data sources.

This article describes the first scenario. (An upcoming article on user-identity management in WebSphere Federation Server will discuss the second scenario. Stay tuned!)


Problem description

Due to the growing popularity of middle-tier servers such as application servers (that enable user-friendly Web-based access to databases) and federation servers (that provide transparent access to heterogeneous data sources), enterprises are now increasingly adopting multi-tier application models. The following is a typical scenario:

You have an insurance application that accesses life insurance claims from a remote IBM DB2® data source and home insurance claims from a remote Oracle data source, and returns a consolidated report for a given customer. Your application runs on an application server, and hosts thousands of users who can log in to the application and view their combined claims.

Typically, all interactions with the database server occur through a database connection established by the client (for example, IBM WebSphere Application Server), and propagated by WebSphere Federation Server using a combination of a user ID and a credential that identifies that client to the database server. For example, all application requests in Figure 1 are being routed to the database server through a connection established by a single application user, APP_USER. In other words, the database server uses the database privileges associated with APP_USER for all authorization checking and auditing for all database access.

Figure 1. Problem scenario: A traditional four-tier model
A traditional four-tier model

As Figure 1 illustrates, there are several inherent problems with the usage of a generic application user such as APP_USER in such multi-tier scenarios:

  • Loss of end-user identity: Enterprises need 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 application server for its own purpose from those performed by the application server on behalf of some user.
  • Over-granting of privileges: The application authorization ID must have all the privileges needed to execute all requests from all users. This violates the Principle of Least Privilege, which is a basic security design principle that recommends that users should only be granted enough privileges to perform their tasks.
  • Weakened security: The current approach requires that the authorization ID used by the application to establish the connection must be granted privileges on all resources that any user requests might access. The application authorization ID therefore becomes a security bottleneck; if it is ever compromised, then all enterprise resources will be exposed.
  • Spill-over between users of the same connection: When several users share a single connection, the changes that one user makes affect all other users. For example, an open withhold cursor or a new temporary table that one user creates may cause unpredictable changes to other users who share the same connection.

Due to these issues, a better approach is required to propagate the real user's identity through the various tiers up to the database server without incurring the overhead of tearing down and re-establishing physical connections for each new end-user.

End-to-end federated trusted contexts is the WebSphere Federation Server solution that efficiently addresses the multi-tier identity assertion problem.


End-to-end federated trusted contexts

End-to-end federated trusted contexts solve the identity assertion problem in multi-tier scenarios involving WebSphere Federation Server V9.5. You configure this feature by creating a trusted context object on the federation server and an identity assertion object (DB2 trusted context or Oracle proxy user) on the remote data source. The trusted context object on WebSphere Federation Server encapsulates the trust attributes for a trusted inbound connection. The identity assertion object on the remote data source defines the trust attributes for establishing a trusted outbound connection.

When this feature is configured, it works as follows:

  • Whenever the inbound connection into WebSphere Federation Server is trusted (either explicitly requested through the new trusted context APIs, or implicitly granted by matching connection attributes), a trusted outbound connection is requested to the data sources.
  • Whenever the inbound connection user is switched, the outbound connection user is also switched.

Figure 2, below, illustrates how you can use end-to-end federated trusted contexts to address the various security issues associated with the multi-tier insurance application scenario introduced in Figure 1.

Figure 2. Identity assertion in an end-to-end federated trusted context
Identity assertion in an end-to-end federated trusted context

To enable end-to-end federated trusted connections, the corresponding security administrator (in other words, a user who holds SECADM authority) must first configure trusted context objects on both the remote DB2 data source and the federation server. The trusted context object on WebSphere Federation Server defines the trust relationship between WebSphere Federation Server and the application server on which the insurance application is hosted. The trusted context object on the remote DB2 data source defines the trust relationship between WebSphere Federation Server and the remote data source.

As illustrated in Step 1 of Figure 2, when the insurance application is first started at the application server, an explicit end-to-end federated trusted connection is established from the application server through WebSphere Federation Server to the data source. The explicit trusted connection is established under the identity of the application user APP_USER. The application user can now use this trusted connection to perform some initial configuration tasks and prepare the environment for the end users. After all the initialization tasks are complete, APP_USER commits the unit of work and prepares to serve end-user requests.

As shown in Step 2 of Figure 2, user Bob now accesses the insurance application to look up all of his insurance claims. The current user ID on the inbound as well as outbound trusted connections is now switched from APP_USER to BOB. In effect, BOB's identity is now asserted on the same physical connection, all the way to the remote data source. Bob's insurance claim requests are now processed using his correct authorization at the data source. Bob's requests are also accurately audited at the remote data source under his own identity. When Bob's requests are completed, his unit of work is committed, and the trusted connection can now be used to serve other user requests.

When user Alice now accesses the insurance application to retrieve her claims (see Step 3 of Figure 2), her identity can be asserted on the same physical connection by switching the connection user ID from BOB to ALICE.

As the above scenario illustrates, end-to-end federated trusted contexts enable accurate authorization checks, user accounting, and auditing based on the correct identity of the end user. Apart from the obvious security benefits, end-to-end federated trusted contexts achieve superior performance when compared with regular non-trusted connections:

  • Different user identities are asserted on the same physical inbound and outbound connection without the need to tear down and create new connections for each new user.
  • If the trusted context object on WebSphere Federation Server and the identity assertion object on the remote data source are configured to enable connection reuse without authentication, you can obtain an additional performance improvement.

Step-by-step guide for end-to-end federated trusted contexts

The following step-by-step guide can help you set up your end-to-end federated trusted contexts environment, as shown in Figure 3:

Figure 3. End-to-end Federated Trusted Contexts : A Complete Scenario
Figure 3
  1. Remote data source setup

    This is a prerequisite for using federated trusted contexts. It differs depending on whether your remote data source is DB2 or Oracle.

    DB2: The security administrator should configure the trusted context object on the remote DB2 data source to define the trust relationship between the data source and WebSphere Federation Server. The following statement (Listing 1) specifies that a trusted connection will be established, provided that the originator is APP_USER and the client is at the IP address (9.44.111.222) of WebSphere Federation Server. Once established, any valid user can use the trusted connection without re-authentication. Make sure that you enable the trusted context.

    Listing 1. Create trusted context object at DB2 data source
    CREATE TRUSTED CONTEXT MY_DB2_TCX 
     BASED UPON CONNECTION USING SYSTEM AUTHID APP_USER
     ATTRIBUTES (ADDRESS ‘9.44.111.222') 
     WITH USE FOR PUBLIC WITHOUT AUTHENTICATION 
     ENABLE

    Oracle: Configure the proxy authentication on the remote Oracle server. Specify that MARY, ALICE, and BOB can all connect using the proxy APP_USER without re-authentication.

    Listing 2. Configure proxy authentication at Oracle data source
    ALTER USER MARY GRANT CONNECT THROUGH APP_USER;
    ALTER USER ALICE GRANT CONNECT THROUGH APP_USER;
    ALTER USER BOB GRANT CONNECT THROUGH APP_USER;

    Please refer to the Appendix for more data source-specific information.

  2. Federation server trusted context definition

    The security administrator must set up the trusted context object on WebSphere Federation Server to allow a trusted connection to be established. The following statement (Listing 3) specifies that APP_USER can establish a trusted connection, provided that the request is initiated at the client's IP address (9.44.111.111). Once established, all valid users can reuse this trusted connection without re-authentication. Make sure that you enable the trusted context.
    Listing 3. Create trusted context object at federation server
    CREATE TRUSTED CONTEXT MY_WFS_TCX 
     BASED UPON CONNECTION USING SYSTEM AUTHID APP_USER 
     ATTRIBUTES (ADDRESS ‘9.44.111.111') 
     WITH USE FOR PUBLIC WITHOUT AUTHENTICATION
     ENABLE
  3. Federation server data source configuration

    On WebSphere Federation Server, you can use the following statements in Listing 4 to configure access to a remote DB2 data source for this scenario. Note that no extra option is needed for this step.
    Listing 4. Configure access to a remote DB2 data source
    CREATE WRAPPER drda; 
    						
    CREATE SERVER udb1 TYPE db2/udb VERSION 9.5 WRAPPER drda 
     AUTHORIZATION "APP_USER" PASSWORD "secret" OPTIONS (DBNAME 'remotedb');

    Consider whether you need to set up user mappings on the federation server.

    • If APP_USER has the same user ID and password on WebSphere Federation Server and the remote data sources, there is no need for user mappings.

      Note: If APP_USER had a different user ID or password on WebSphere Federation Server and a data source, a user mapping is needed.
    • All valid database users can reuse the trusted connections established by APP_USER without re-authentication. Therefore, users such as MARY and ALICE who have the same user ID on WebSphere Federation Server and the remote data source do not require any user mappings.
    • User JOE on WebSphere Federation Server maps to user JOESMITH on the remote data source. As a result, the security administrator must create a trusted user mapping for JOE using the statement in Listing 5. A user mapping with an option USE_TRUSTED_CONTEXT set to 'Y' is considered a trusted user mapping. A trusted user mapping can only be created by a user who holds the SECADM authority to prevent users from mapping themselves to more privileged users on the remote data sources. The user mapping for JOE is only required to map between the inbound and the outbound authorization ID. The REMOTE_PASSWORD option does not need to be specified since JOE can reuse the trusted connections established by APP_USER without re-authentication.
      Listing 5. Create a trusted user mapping
      CREATE USER MAPPING FOR JOE SERVER udb1 
      OPTIONS ( REMOTE_AUTHID 'JOESMITH', USE_TRUSTED_CONTEXT 'Y');

      Note: Since this user mapping is specified without a REMOTE_PASSWORD clause, it does not have the administration pain points associated with password maintenance.

    • Any other user who has different user IDs and different passwords on WebSphere Federation Server and the data source would need to define a trusted user mapping with both REMOTE_AUTHID and REMOTE_PASSWORD options defined.
  4. User applications

    After the initial setup is complete, application users can begin using the federated trusted contexts:
    1. Establish an end-to-end federated trusted connection

      When the application is started, a trusted inbound connection is requested for the application user APP_USER. The first federated request that accesses the remote DB2 data source establishes a trusted outbound connection for APP_USER. As Step 4d in Figure 3 shows, this explicit end-to-end federated trusted connection can be used by APP_USER to perform sundry housekeeping tasks on the data source and prepare it for use by the enterprise end users.
    2. Switch user on the end-to-end federated trusted connection

      When an end user, such as Bob, begins using the application, the inbound user ID is switched from APP_USER to BOB. The first federated request issued by BOB that accesses the remote DB2 data source causes the outbound trusted connection user ID to also get switched to BOB. As Step 5d in Figure 3 illustrates, BOB's identity is now asserted all the way to the DB2 data source, and his identity is used for accurate authorization, auditing, and so on.
    Listing 6. Establish and use end-to-end federated trusted connections
    int main(int argc, char *argv[])
    {
      SQLHANDLE henv;                /* environment handle */
      SQLHANDLE hdbc1;               /* connection handle */
      SQLHANDLE hstmt;               /* statement handle */
      char origUserid[10] = "APP_USER";
      char origPassword[10] = "secret";
      char reuseUserid[10] = "BOB";
      char dbName[10] = "testdb";
    
      /* Allocate the handles */
      SQLAllocHandle( SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv );
      SQLAllocHandle( SQL_HANDLE_DBC, henv, &hdbc1 );
    
      /* Set the trusted connection attribute */
      SQLSetConnectAttr( hdbc1, SQL_ATTR_USE_TRUSTED_CONTEXT, (SQLPOINTER)SQL_TRUE,
    						SQL_IS_INTEGER );
    
      /* Establish a trusted inbound connection for user APP_USER from WAS
         to WFS. This requires a password to be specified. */
      SQLConnect( hdbc1, (SQLCHAR *)dbName, SQL_NTS, origUserid, SQL_NTS,
    						origPassword, SQL_NTS );
     
      /* Allocate statement handle */
      SQLAllocHandle(SQL_HANDLE_STMT, hdbc1, &hstmt);
    
      /* The first call to remote DB2 data source will setup trusted outbound
         connection for user APP_USER from WFS to remote DB2 data source. */
      SQLExecDirect (hstmt, (SQLCHAR *) "SELECT * FROM patents_nn", SQL_NTS);
    
      /* Perform some work under user ID "APP_USER"  */
      . . . . . . . . . . .
    
      /* Commit the work. End the transaction.  */
      SQLEndTran(SQL_HANDLE_DBC, hdbc1, SQL_COMMIT);
    
      /* Free statement handle */
      SQLFreeHandle(SQL_HANDLE_DBC, hstmt);
    
      /* At the transaction boundary, switch the inbound user ID on the trusted
         connection from APP_USER to BOB. Note: Password is not required
         since PUBLIC appears in the "with use for" clause "without authentication"
         in the MY_WFS_TCX trusted context object.  */
      SQLSetConnectAttr (hdbc1, SQL_ATTR_TRUSTED_CONTEXT_USERID,
    						reuseUserid, SQL_IS_POINTER );
    
      /* Allocate statement handle */
      SQLAllocHandle(SQL_HANDLE_STMT, hdbc1, &hstmt);
    
      /* The first call to the remote data source after switching inbound user will
         switch the outbound user ID as well (from APP_USER to BOB).
         Since no user mapping was specified for user BOB, the same user ID
         will be passed on to the outbound connection.
         Password is not required since PUBLIC appears in the "with use for" clause
         "without authentication" in the MY_DB2_TCX trusted context object. */
      SQLExecDirect (hstmt, (SQLCHAR *) "SELECT * FROM patents_nn", SQL_NTS);
    
      /* Perform new work using user ID "BOB" */
      . . . . . . . . .
    
      /* Commit the work. End the transaction. */
      SQLEndTran(SQL_HANDLE_DBC, hdbc1, SQL_COMMIT);
    
      . . . . . . . . .
    
      /* Disconnect from the database */
      SQLDisconnect( hdbc1 );
    
      /* Cleanup, free handles, etc */
      . . . . . . . . .
    
      return 0;
    }  /* end of main */

Troubleshooting federated trusted connections

  • Request for a federated trusted connection fails

    When a request for an explicit end-to-end federated trusted connection fails, warning SQL20360W is returned. When an implicit federated trusted connection attempt fails, no message is returned. In both cases, a regular non-trusted connection is created, if possible. If your application requests a trusted connection, but is granted a regular non-trusted connection, check to see if the following problems exist:
    • Make sure the client is using TCP/IP to communicate with the federation server. Remember that if your client and federated server are on the same machine, then DB2 uses IPC by default. Be sure to catalog the federated database to use TCP/IP.
    • Ensure that you have created and enabled a trusted context object on the federation server. A trusted context object is enforced only when it is enabled using the ENABLE keyword in the CREATE / ALTER TRUSTED CONTEXT DDL statement.
    • If your application requests an explicit trusted connection, you cannot set the database server authentication type to CLIENT.
    • Finally, verify that the trust attributes in the trusted context object on the federated database server actually match the trust attributes that are being presented in your connection request. For example, the IP address specified in a trusted context object might be incorrect, or your network encryption attributes may not be strong enough to be accepted by the trusted context.
  • Attempt to switch users on a federated trusted connection fails

    If your application experiences an error while attempting to switch users on a federated trusted connection, check to see if the following problems exist:
    • If SQL1060N is returned, verify that the user indeed has connect privileges to the federated database.
    • If your application receives a SQL20361N, verify the following:
      • Ensure that the user ID or PUBLIC is defined in the WITH USE FOR clause of the trusted context.
      • Switching the user is allowed with authentication, but your application presents no credentials or the wrong credentials.
      • Verify that the switch-user request has been made at a transaction boundary. Either commit or roll back your transaction before resubmitting the request.
      • Finally, verify that the trusted context object on the federation server has not been disabled, dropped, or altered since your connection was established.
  • Attempt to add / modify / delete federated trusted context options fails

    If your application experiences an error while attempting to create or alter a user mapping with the USE_TRUSTED_CONTEXT option, then verify the following:
    • You must hold the SECADM authority if you are attempting to create or drop a user mapping with the USE_TRUSTED_CONTEXT option defined.
    • You must hold the SECADM authority if you are attempting to alter a user mapping to add, set, or drop the USE_TRUSTED_CONTEXT option.
    • You can only alter the REMOTE_PASSWORD option of your trusted user mapping. Ensure that the new value is not empty.

Restrictions

  • The federated trusted contexts feature can provide connection reuse only for the following data sources that support identity-assertion features:
    1. DB2 for Linux®, UNIX®, and Windows® V9.5 and later
    2. DB2 for z/OS® V9 and later
    3. Oracle
    For all other data sources, WebSphere Federation Server can only make regular, non-trusted outbound connections. When the inbound connection is switched, WebSphere Federation Server will disconnect and reconnect to such data sources. Therefore, there will be no performance advantage for using federated trusted contexts with other data sources. Note that for such unsupported data sources, a reconnect will require both a user ID and a password.
  • Explicit trusted connections can only be requested from APIs that support trusted connection requests (namely, CLI, ODBC, JDBC, and XA).

Conclusion

End-to-end federated trusted contexts in WebSphere Federation Server V9.5 is a new feature that provides several benefits, including:

  • Improved access control by preserving the identities of the end users accessing the remote databases
  • Better user accountability through auditing to distinguish transactions performed by different users
  • Principle of least privilege, whereby users are granted only as many privileges as they need to accomplish their tasks
  • Individualized security management to ensure that no single authorization ID is a security bottleneck that can compromise the enterprise resources
  • Complete cleanup of the user environment when a connection is switched to a new user, thereby protecting users from spill-overs from previous connection users

The federated trusted contexts feature provides users improved security, enhanced performance, and ease of administration. Federated trusted contexts, along with other new security features such as federated database roles and C user mapping plug-ins, makes WebSphere Federation Server V9.5 your ideal choice for a secure information integration solution.


Appendix: Identity assertion features in data sources

DB2 trusted contexts

DB2 (for Linux, UNIX, and Windows, and z/OS) has introduced a new database security object called trusted context. A trusted context addresses the problem of establishing a trusted relationship between DB2 and an external entity, such as a middleware server (for example, WebSphere Application Server) or a federation server (e.g. WebSphere Federation Server). A series of trust attributes are evaluated to determine if a specific context can be trusted. A database connection is referred to as a trusted connection when the connection attributes match the attributes of a unique trusted context defined at the DB2 server. The " trust" is based on:

  • Primarily, the authorization ID that established the physical connection. (Note: Only one trusted context object can be associated with a primary authorization ID.)
  • Optionally, certain "trust attributes," in other words:
    • IP address or domain name
    • Network encryption level

The relationship between a database connection and a trusted context is established when the connection to the server is first made and that relationship remains for the life of that connection. Once established, this relationship allows the initiator of such a connection to acquire additional capabilities. These additional capabilities vary, depending on whether the trusted connection is explicit or implicit.

An explicit trusted connection is a trusted connection that is explicitly requested by the user. Explicit trusted connections have certain enhanced capabilities:

  • The ability to switch the connection user to a different user ID with or without authentication. This is achieved through XA, JDBC, ODBC, and CLI API functions that enable switching users. Only users with CONNECT privileges on the database can re-use a trusted connection. When a trusted connection user is switched, it resets all the connection attributes, including cursor with hold, isolation, bind options, codepage, and so on. No traces of the previous user are left. In effect, it is like a new connection setup for the switched user.
  • The ability for explicit trusted connection users to acquire additional privileges during the scope of the trusted connection that may not be available to them otherwise.

An implicit trusted connection is one that is not explicitly requested by the user. When all attributes of an incoming connection request match all the trust attributes of any trusted context object on the DB2 server, the DB2 server implicitly grants a trusted connection. Such a connection is called an Implicit trusted connection. It does not require any special APIs to be used for the connection request. An implicit trusted connection allows the initiator of such a trusted connection to acquire additional privileges that may not be available to them otherwise. However, an implicit trusted connection cannot be reused by switching users.

DB2 uses the CREATE TRUSTED CONTEXT statement to create trusted context objects. Corresponding ALTER, DROP, and COMMENT DDL statements are also available.

Oracle proxy authentication

Oracle allows the middle tier to set up a number of lightweight user sessions within a single database connection, each of which uniquely identifies a connected user. These lightweight sessions reduce the network overhead of creating separate network connections from the middle tier to the database. The application can switch between these sessions as required to process transactions on behalf of users.

Oracle uses the alter user DDL statement to register proxy users.

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management, WebSphere
ArticleID=276850
ArticleTitle=End-to-end federated trusted contexts in WebSphere Federation Server V9.5
publish-date=12132007