|
|
|
|
|
|
Authentication
Authentication allows communicating processes to mutually prove identification. The BEA Tuxedo authentication plug-in interface can accommodate various security-provider authentication plug-ins using various authentication technologies, including shared-secret password, one-time password, challenge-response, and Kerberos. The interface closely follows the generic security service (GSS) application programming interface (API) where applicable; the GSSAPI is a published standard of the Internet Engineering Task Force. The authentication plug-in interface is designed to make integration of third-party vendor security products with the BEA Tuxedo system as easy as possible, assuming the security products have been written to the GSSAPI.
Authentication Plug-in Architecture
The underlying plug-in interface for authentication security is implemented as a single plug-in. The plug-in may be the default authentication plug-in or a custom authentication plug-in.
Understanding Delegated Trust Authentication
Direct end-to-end mutual authentication in a distributed enterprise middleware environment such as the BEA Tuxedo system can be prohibitively expensive, especially when accomplished with security mechanisms optimized for long-duration connections. It is not efficient for clients to establish direct network connections with each server process, nor is it practical to exchange and verify multiple authentication messages as part of processing each service request. Instead, the BEA Tuxedo system implements a delegated trust authentication model, as shown in the following figure.
Delegated Trust Authentication Model
A Workstation client authenticates to a trusted system gateway process, the Workstation Handler (WSH), at initialization time. A native client authenticates within itself, as explained later in this discussion. After a successful authentication, the authentication software assigns a security token to the client. A token is an opaque data structure suitable for transfer between processes. The WSH safely stores the token for the authenticated Workstation client, or the authenticated native client safely stores the token for itself.
As a client request flows through a trusted gateway, the gateway attaches the client's security token to the request. The security token travels with the client's request message, and is delivered to the destination server process(es) for authorization checking and auditing purposes.
In this model, the gateway trusts that the authentication software will verify the identity of the client and generate an appropriate token. Servers, in turn, trust that the gateway process will attach the correct security token. Servers also trust that any other servers involved in the processing of a client request will safely deliver the token.
Establishing a Session
The following figure shows the control flow inside the BEA Tuxedo system while a session is being established between a Workstation client and the WSH. The Workstation client and WSH are attempting to establish a long-term mutually authenticated connection by exchanging messages.
Client-WSH Authentication
The initiator process (may be thought of as a middleware client process) creates a session context by repeatedly calling the BEA Tuxedo "initiate security context" function until a return code indicates success or failure. A session context associates identity information with an authenticated user.
When a Workstation client calls tpinit(3c) for C or TPINITIALIZE(3cbl) for COBOL to join an application, the BEA Tuxedo system begins its response by first calling the internal "acquire credentials" function to obtain a session credential handle, and then calling the internal "initiate security context" function to obtain a session context. Each invocation of the "initiate security context" function takes an input session token (when one is available) and returns an output session token. A session token carries a protocol for verifying a user's identity. The initiator process passes the output session token to the session's target process (WSH), where it is exchanged for another input token. The exchange of tokens continues until both processes have completed mutual authentication.
A security-provider authentication plug-in defines the content of the session context and session token for its security implementation, so BEA Tuxedo authentication security must treat the session context and session token as opaque objects. The number of tokens passed back and forth is not defined, and may vary based on the architecture of the authentication system.
For a native client initiating a session, the initiator process and the target process are the same; the process may be thought of as a middleware client process. The middleware client process calls the security provider's authentication plug-in to authenticate the native client.
Getting Authorization and Auditing Tokens
After a successful authentication, the trusted gateway calls two BEA Tuxedo internal functions that retrieve an authorization token and an auditing token for the client, which the gateway stores for safekeeping. Together, these tokens represent the user identity of a security context. The term security token refers collectively to the authorization and auditing tokens.
When default authentication is used, the authorization token carries two pieces of information:
In addition, when default authentication is used, the auditing token carries the same two pieces of information: principal name and application key.
Like the session token, the authentication and auditing tokens are opaque; their contents are determined by the security provider. The authorization token can be used for performing authorization (permission) checks. The auditing token can be used for recording audit information. In some applications, it is useful to keep separate user identities for authorization and auditing.
Replacing Client Tokens with Server Tokens
As shown in the following diagram, there are situations where a client service request forwarded by a server takes on the identity of the server. The server replaces the client tokens attached to the request with its own tokens and then forwards the service request to the destination service.
Server Permission Upgrade-Example
The feature demonstrated in the preceding diagram is known as server permission upgrade, which operates in the following manner: whenever a server calls a dot service (a system-supplied service having a beginning period in its name-such as .TMIB), the service request takes on the identity of the server and thus acquires the access permissions of the server. A server's access permissions are those of the application (system) administrator. Thus, certain requests that would be denied if the client called the dot service directly would be allowed if the client sent the requests to a server, and the server forwarded the requests to the dot service. For more information about dot services, see the .TMIB service description on the MIB(5) reference page in BEA Tuxedo File Formats and Data Descriptions Reference.
Implementing Custom Authentication
You can provide authentication for your application by using the default plug-in or a custom plug-in. You choose a plug-in by configuring the BEA Tuxedo registry, a tool that controls all security plug-ins.
If you want to use the default authentication plug-in, you do not need to configure the registry. If you want to use a custom authentication plug-in, however, you must configure the registry for your plug-in before you can install it. For more detail about the registry, see Setting the BEA Tuxedo Registry.
See Also
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|