Method for providing and utilizing a network trusted context

A method for establishing a connection between a data server and a middleware server is disclosed. The method includes defining a plurality of trust attributes corresponding to a trusted context between the middleware server and the data server and validating the plurality of trust attributes against a plurality of attributes corresponding to the middleware server. The plurality of attributes provided in a connection request. The method also includes establishing the trusted context based on the validating the plurality of trust attributes.

FIELD OF THE INVENTION

The present invention relates to connections between servers and more particularly to a method for providing a trusted context between servers.

BACKGROUND OF THE INVENTION

FIG. 1depicts a conventional system10for allowing end users to access data through a data server. The conventional system10includes a conventional middleware server20, a conventional data server40, a database50, and a network30connecting the conventional middleware server20to the conventional data server40. End users (not shown) can connect to the conventional middleware server20, and thus the data server40, through clients22, and24.

FIG. 2depicts a conventional method60for accessing data in the database50. The conventional method50commences after an end user logs onto the conventional middleware server40. The conventional middleware server20requests a connection with the conventional data server40, via step62. To do so, the conventional middleware server20provides the conventional data server40with a user identification for the conventional middleware server20. The conventional data server40validates this user identification for the conventional middleware server20, via step64. If the conventional middleware server is authorized to connect to the conventional data server40, then a connection is established, via step66. Using this connection, the database50can be accessed through the conventional middleware server20and returned to end users, via step68. The connection may be terminated at the end of the session, via step70.

Although the conventional system10and method60function, one of ordinary skill in the art will readily recognize that there are significant drawbacks. The use of the database50is managed through the connection between the conventional data server40and the conventional middleware server20established in step66. However, this connection is established based on the user identification for the conventional middleware server20. The identity of the end user that is utilizing the database50is not tracked. Consequently, there is a loss of end user accountability. Furthermore, because access to the database50is managed based upon the user identification of the conventional middleware server20, that middleware server user ID identification is granted all the privileges required for the actions of all of the end users connecting to the database50through the conventional middleware server20. This results in weakened security since because every end user has access to the same set of privileges on the database40. For example, all end users of the conventional middleware server20may access the same data on the database40even though the end user IDs themselves may not otherwise be authorized to access the data. Security for the database50is thereby weakened. Alternatively, each time a new end user accesses the database40through the conventional middleware server20, the connection between the conventional middleware server20and the data server40is re-established based on the identification of the end user. The method60is thus repeated and the conventional middleware server20re-authenticated each time a new end user desires access to the database50. Providing new connections for each end user ameliorates the weakening of security discussed above. Furthermore, the connection may allow the end user to obtain only those privileges to which the end user is entitled. However, overhead is greatly increased and performance suffers significantly.

Accordingly, what is needed is an improved mechanism for managing connections between a middleware server and a data server. The present invention addresses such a need.

BRIEF SUMMARY OF THE INVENTION

The present invention provides a method for establishing a connection between a data server and a middleware server is disclosed. The method comprises defining a plurality of trust attributes corresponding to a trusted context between the middleware server and the data server and validating the plurality of trust attributes against a plurality of attributes corresponding to the middleware server. The plurality of attributes provided in a connection request. The method also comprises establishing the trusted context based on the validating the plurality of trust attributes.

According to the method disclosed herein, the present invention allows a trusted connection to be established and aspects of the relationships between the middleware server, data server, and/or end users managed using roles.

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides a method for establishing a connection between a data server and a middleware server is disclosed. The method comprises defining a plurality of trust attributes corresponding to a trusted context between the middleware server and the data server and validating the plurality of trust attributes against a plurality of attributes corresponding to the middleware server. The plurality of attributes are provided directly or indirectly in a connection request. The method also comprises establishing the trusted context based on the validating the plurality of trust attributes.

The present invention will be described in terms of a particular data servers, middleware servers, and networks. However, one of ordinary skill in the art will readily recognize that the method can operate for other servers, middleware servers and networks having other and/or additional components and which are connected in a different manner not inconsistent with the present invention.

FIG. 3is a block diagram depicting one embodiment of a system100in accordance with the present invention that provides a trusted context for connecting between a middleware server and a data server. The system100includes a middleware server120connected to a data server140through a network130. The middleware server120is connected to clients122and124, which may be utilized by end users to connect to the middleware server120. The middleware server120also preferably includes code126used in creating a trusted context. The code126may allow the middleware server120to request the connection, request that the connection be made as a trusted context if desired, and a mechanism for exchanging information relating to the trusted context, such as tokens relating to the trusted context (described below) that may be passed between the middleware server120and data server140, as well as APIs used in establishing the trusted context.

The data server140is coupled with a database150and manages access to the database150. The data server140includes code180for managing connections with the middleware server120. The code180includes a validation block182and a connection block184. The validation block182is used to validate attributes of the middleware server. The connection block184can be used to manage other aspects of establishing a connection in accordance with the present invention between the middleware server120and the data server140. Note that the code180may include a different arrangement of components182and184in order to perform the desired functions, as well as other and/or additional components. The data server140also includes data160and170corresponding to trusted connections. At least one of the data160and170corresponds to a trusted connection established between the middleware server120and the data server140. The data160and170includes trusted attributes162and172, respectively, and may include roles164and174, respectively, for the corresponding connection. Note that although roles164and174are described as being associated with a user within a particular trusted context, they can be associated either to all users of the trusted context level or to a specific user within the context. In such an embodiment, individual users can obtain additional privileges using the role, but only through the trusted context. This prevents end users from accessing objects outside of the protected middleware server120through the role when connecting to the database150outside of the trusted context.

The system100can create a trusted context between the middleware server120and the data server140. A trusted context is one which is believed to be secure for at least some purpose and is a candidate for re-use with or without re-authentication of the end user.

Trusted attributes162and172are used to determine whether a particular request for a connection is a candidate for a trusted context. In one embodiment, only requests asking for a trusted context would be candidates for a trusted context. In another embodiment, any request from the middleware server120is a candidate for a trusted context. Examples of trusted attributes162and172include but are not limited to the user identification for the middleware server120, attributes of the specific connection that can be trusted such as the system authorization id, encryption, authentication, protocol and job name, as well as the IP address of or domain name for the middleware server connection to the data server140. In an alternate embodiment, attributes of the client122or124using the connection might be a trusted attribute162or172, such as the IP address of the client122or124. In such an embodiment, the middleware server120would provide the identity of the client122or124. For example, trusted attributes162or172may take the form: SYSTEM AUTHID WASADMI; Address 9.26.113.204, Address 9.26.113.208, and Address 9.26.113.219. Such trusted attributes162or172can be used to validate creation of a trusted context for a middleware server having a user identification WASADMI, for connections having addresses 9.26.113.204, and 9.26.113.218.

Roles164and174can be used to manage aspects, such as privileges granted, of a trusted connection. Examples of analogous roles can be found SQL. For example, access to database objects of the database150, authorization of end users, and other privileges granted to end users may be managed through the use of roles. A role164and/or174could encompass all end users in the trusted context. For such a role164or174, any privilege granted to the role164or174would be granted to the end user. A role164and/or174could also be associated with individual end users or subsets of the end users of the trusted context. For such a role164or174, only the associated the end user(s) would inherit the privileges of the role164or174. Such roles164and174may thus include data related not only to the privileges granted, but information, such as end user identification, required for the privilege to be granted. Such roles164or174would also override relevant defaults for the trusted context, replacing the appropriate defaults with rules for the roles164and174. Thus, the roles164and174allow the trusted context to be managed at a finer level.

FIG. 4is a high-level flow chart depicting one embodiment of a method200in accordance with the present invention for establishing and using a trusted context for a middleware server120and a data server140. For clarity, the method200is described in the context of the system100. However the method200might be used with another system (not shown). Thus, the method200is described in the context of a connection between the middleware server120and the data server140. It is also presumed that the data160corresponds to the trusted context.

Data160for the trusted context is defined, via step202. Step202includes defining the trust attributes162. Step202is preferably performed by a database administrator (not shown) having the authority to define trusted contexts for the data server140. In one embodiment, step202may include defining any roles164, if any, associated with the trusted context as a whole and/or to individual end users within that context. However, at least the trust attributes are defined. Attributes of the middleware server120are validated against the trust attributes162, via step204. Step204is preferably performed in response to a request for a connection from the middleware server120. The request for the connection would include attributes of the middleware server120, such as the address and user identification of the middleware server. In one embodiment, the middleware server120can provide additional information in the request, such as attributes of the client122or124and/or attributes of the end user. The trusted connection may then be established based upon the results of the validation, via step206. In one embodiment, if the attributes match the trust attributes, then the trusted connection is established in step204. If the attributes do not match the trust attributes, then in one embodiment, a connection that is not trusted could be established or an error message could be provided and the connection suspended.

Using the method200, a trusted connection may be established. Such a connection might be reused and user privileges may be managed with a finer granularity. For example, end user(s) may be required to input their user identification before using the trusted context. In addition, access to certain database objects, such authorized users, and other features of the trusted connection may be validated. Consequently, security and performance may be improved.

FIG. 5is a more detailed flow chart depicting one embodiment of a method250in accordance with the present invention for establishing and using a trusted context for a middleware server120and a data server140. For clarity, the method250is described in the context of the system100. However the method250might be used with another system (not shown). Thus, the method250is described in the context of a connection between the middleware server120and the data server140. It is also presumed that the data160corresponds to the trusted context.

Data160for the trusted context is defined, via step252. Step252includes defining the trust attributes162. Step252is preferably performed by a database administrator (not shown) having the authority to define trusted contexts for the data server140. In one embodiment, step252may include defining any roles164, if any, associated with the trusted context as a whole and/or for individual end users within the context.

A request for connection is made by the middleware server120, via step254. Step254includes the middleware server120providing the appropriate attributes for validation. The attributes of the middleware server120may include such as the address and user identification of the middleware server. In one embodiment, additional information such as attributes of the client122or124, such as their addresses, or attributes of the end user such as their user identification, might be provided by the middleware server120in the request.

In response to the request for a connection from the middleware server120, the attributes of the middleware server120are validated against the trust attributes162, via step256. Step256is performed by the data server140. If the attributes of the middleware server120match the trust attributes162, then the connection having the trusted context is established, via step258. If the attributes do not match the trust attributes, then in one embodiment, a connection that is not trusted could be established or an error message could be provided and the connection suspended. Once the connection having the trusted context is established, the connection is managed based upon the trusted context, via step260. In particular, step260utilizes the roles164and other data160to manage the trusted context. For example, access to certain data objects of the database160may be restricted for certain end users. Some or all of the users may also be able to reuse the connection with or without re-authentication. Moreover, the trusted context may have a time limit. In such an embodiment, step260would include terminating the connection after the time limit expires.

Using the method250, a trusted connection may be established. Such a connection might be reused and user privileges may be managed with a finer granularity. For example, end user(s) may be required to input their user identification before using the trusted context. In addition, access to certain database objects, such authorized users, and other features of the trusted connection may be validated. Consequently, security and performance may be improved.

A method for providing a trusted context has been disclosed. The present invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and any variations would be within the spirit and scope of the present invention. Software written according to the present invention is to be stored in some form of computer-readable medium, such as memory, CD-ROM or transmitted over a network, and executed by a processor. Consequently, a computer-readable medium is intended to include a computer readable signal which, for example, may be transmitted over a network. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.