Release 2 (9.2)
Part Number A96590-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Application Developer's Guide - Fundamentals Release 2 (9.2) Part Number A96590-01 |
|
This chapter provides information about proxy authentication in a multi-tier system. Topics in this chapter are presented in the following sections:
In multi-tier environments, proxy authentication allows you to control the security of middle-tier applications by preserving client identities and privileges through all tiers, and auditing actions taken on behalf of clients. For example, this feature allows the identity of a user using a web application (also known as a "proxy") to be passed through the application to the database server.
Three-tier systems provide many benefits to organizations.
In addition, Oracle proxy authentication delivers the following security benefits:
While three-tier computing provides many benefits, it raises a number of new security issues. These issues are described in the following sections:
Most organizations want to know the identity of the actual user who is accessing the database, for reasons of access control or auditing. User accountability is diminished if the identity of the users cannot be traced through all tiers of the application.
Furthermore, if only the application server knows who the user is, then all per-user security enforcement must be done by the application itself. Application-based security is very expensive. If each application that accesses the data must enforce security, then security must be re-implemented in each and every application. It is often preferable to build security on the data itself, with per-user accountability enforced within the database.
Some organizations are willing to accept three-tier systems within the enterprise, in which "all-privileged" middle tiers, such as transaction processing (TP) monitors, can perform all actions for all users. In this architecture, the middle tier connects to the database as the same user for all application users. It therefore needs to have all privileges that application users need to do their jobs.
This computing model can be undesirable in the Internet, where the middle tier resides outside, on, or just inside a firewall. More desirable, in this context, is a limited trust model, in which the identity of the real client is known to the data server, and the application server (or other middle tier) has a restricted privilege set.
Also useful is the ability to limit the users on whose behalf a middle tier can connect, and the roles the middle tier can assume for the user. For example, many organizations would prefer that users have different privileges depending on where they are connecting from. A user connecting to a web server or application server on the firewall might only be able to use very minimal privileges to access data, whereas a user connecting to a web server or application server within the enterprise might be able to exercise all privileges she is otherwise entitled to have.
Accountability through auditing is a basic principle of information security. Most organizations want to know on whose behalf a transaction was accomplished, not just that a particular application server performed a transaction. A system must therefore be able to differentiate between a user performing a transaction, and an application server performing a transaction on behalf of a user.
Auditing in three-tier systems should be tied to the issue of knowing the real user: if you cannot preserve the user's identity through the middle tier of a three-tier application, then you cannot audit actions on behalf of the user.
In client/server systems, authentication tends to be straightforward: the client authenticates to the server. In three-tier systems authentication is more difficult, because there are several potential types of authentication.
Client authentication to the middle tier is clearly required if a system is to conform with basic security principles. The middle tier is typically the first gateway to useful information that the user can access. Users must, therefore, authenticate to the middle tier. Note that such authentication can be mutual; that is, the middle tier authenticates to the client just as the client authenticates to the middle tier.
Since the middle tier must typically initiate a connection to a database to retrieve data (whether on its own behalf or on behalf of the user), this connection clearly must be authenticated. In fact, the Oracle9i database does not allow unauthenticated connections. Again, middle tier to database authentication can also be mutual if using a protocol that supports this, such as SSL.
Client re-authentication from the middle tier to the database is problematic in three-tier systems. The username might not be the same on the middle tier and the database. In this case, users may need to reenter a username and password, which the middle tier uses to connect on their behalf. Or, more commonly, the middle tier may need to map the username provided, to a database username. This mapping is often done in an LDAP-compliant directory service, such as Oracle Internet Directory.
For the client to re-authenticate himself to the database, the middle tier either needs to ask the user for a password (which it then must be trusted to pass to the database), or the middle tier must retrieve a password for the user and use that to authenticate the user. Both approaches involve security risks, because the middle tier is trusted to handle the user's password properly, and not to use it maliciously.
One of the only cases for which re-authentication does not involve trusting the middle tier occurs when a middle tier downloads an applet to a client, and the client connects directly to the database via the applet. In this case, the application server is literally just that: it serves the application (applet) to the user, and has no part in further authentication of the user.
Re-authenticating the client to the back-end database is not always beneficial. First, two sets of authentication handshakes per user involves considerable network overhead. Second, you must trust the middle tier to have authenticated the user. (You clearly must trust the middle tier if it retrieves or otherwise is privy to the user's password.) It is therefore not unreasonable for the database to simply accept that the middle tier has performed proper authentication. In other words, the database accepts the identity of the real client without requiring the real client to authenticate herself.
For some authentication protocols, client re-authentication is just not possible. For example, many browsers and application servers support the Secure Sockets Layer (SSL) protocol. Both the Oracle9i database (through Oracle Advanced Security) and Oracle9i Internet Application Server support the use of SSL for client authentication. However, SSL is a point-to-point protocol, not an end-to-end protocol. It cannot be used to re-authenticate a browser client (through the middle tier) to the database.
The reason for this is that a user cannot securely give up his private key to the middle tier in order for the re-authentication of the client to occur. Once the user's private key is compromised, the user's very identity is compromised. In addition, there is no way to tunnel through a middle tier so that the authentication of the browser client to the database can occur directly.
In short, organizations deploying three-tier systems require flexibility as regards re-authentication of the client. In some cases, they cannot re-authenticate the client; in other cases, they may choose whether or not to re-authenticate the client.
The following sections explain how Oracle9i provides solutions to specific authentication issues.
Many organizations want to know who the user is through all tiers of an application, without sacrificing the benefits of a middle tier. Oracle9i supports multiple ways of preserving user identity through the middle tier of an application. For enterprise users, users managed in Oracle Internet Directory who access a shared schema in the database, or database users, Oracle9i provides proxy authentication in OCI or thick JDBC. For application users, users known to an application but unknown to the database, Oracle9i supports application user proxy authentication in OCI, thick JDBC, and thin JDBC.
For enterprise users or database user, OCI or thick JDBC enables a middle tier to set up, within a single database connection, a number of lightweight user sessions, 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.
The full authentication sequence from the client to the middle tier to the database occurs as follows:
The OCISessionBegin call will fail if the application server is not allowed to proxy on behalf of the client by the administrator, or if the application server is not allowed to activate the specified roles.
"Least privilege" is the principle that users should have the fewest privileges necessary to perform their duties, and no more. As applied to middle tier applications, this means that the middle tier should not have more privileges than it needs. Oracle9i enables you to limit the middle tier such that it can connect only on behalf of certain database users, using only specific database roles. You cannot limit the ability of the middle tier to connect on behalf of enterprise users or limit the user of enterprise roles in OCI or thick JDBC lightweight connections.
For example, suppose that user Sarah wants to connect to the database through a middle tier, appsrv (which is also a database user). Sarah has multiple roles, but it is desirable to restrict the middle tier to exercise only the clerk role on her behalf.
A DBA could effectively grant permission for appsrv to initiate connections on behalf of Sarah using her clerk role only, using the following syntax:
ALTER USER Sarah GRANT CONNECT THROUGH appsrv WITH ROLE clerk;
By default, the middle tier cannot create connections for any client. The permission must be granted on a per-user basis.
To allow appsrv to use all of the roles granted to the client Sarah, the following statement would be used:
ALTER USER sarah GRANT CONNECT THROUGH appsrv;
Each time a middle tier initiates a lightweight (OCI) or thick JDBC session for another database user, the database verifies that the middle tier is privileged to connect for that user, using the role specified.
You can limit the privilege of the middle tier to connect on behalf of an enterprise user by granting to the middle-tier the privilege to connect as the underlying database user. For instance, if the enterprise user is mapped to the APPUSER schema, you must at least grant to the middle tier the ability to connect on behalf of APPUSER. Otherwise, attempts to create a session for the enterprise user will fail.
In the case of authentication with a database password, the password of the client is passed to the middle-tier server. The middle-tier server then passes the password as an attribute to the data server for verification. The main advantage to this is that the client machine does not have to have Oracle software actually installed on it.
As described above, it is not always beneficial to re-authenticate users to the database after they have been authenticated by the middle tier. However, if you wish to do this for an added measure of security, you can pass the database the user's password using the OCI_ATTR_PASSWORD attribute of the OCIAttrSet call.
.
| See Also:
For more information about security in three-tier architectures, see the Oracle Call Interface Programmer's Guide. |
If the middle tier is connecting to the database as client who is an enterprise user, either the distinguished name or the X.509 certificate containing the distinguished name is passed over instead of the database user name. If the user is a password-authenticated enterprise user, then the middle tier must provide, as a minimum, a globally unique name for the user. The database uses this name to look up the user in Oracle Internet Directory.
To pass over the distinguished name of the client, the application server would call OCIAttrSet() with the following pseudo-interface.
OCIAttrSet(OCISession *session_handle, OCI_HTYPE_SESSION, lxstp *distinguished_name, (ub4) 0, OCI_ATTR_DISTINGUISHED_NAME, OCIError *error_handle);
To pass over the entire certificate, the middle tier would use the following pseudo-interfaces:
OCIAttrSet(OCISession *session_handle, OCI_HTYPE_SESSION, ub1 *certificate, ub4 certificate_length, OCI_ATTR_CERTIFICATE, OCIError *error_handle);
If the type is not specified, then the server will use its default certificate type of X.509.
If using proxy authentication for password-authenticated enterprise users, use the same OCI attributes as for database users authenticated by password (e.g. OCI_ATTR_USERNAME). The database first checks the username against the database; if no user is found, then the database checks the username in the directory. This username must be globally unique.
The proxy authentication features of Oracle9i enable you to audit actions that a middle tier performs on behalf of a user. For example, suppose an application server hrappserver creates multiple lightweight sessions for users Ajit and Jane. A DBA could enable auditing for SELECTs on the bonus table that hrappserver initiates for Jane as follows:
AUDIT SELECT TABLE BY hrappserver ON BEHALF OF Jane;
Alternatively, the DBA could enable auditing on behalf of multiple users (in this case, both Jane and Ajit) connecting through a middle tier as follows:
AUDIT SELECT TABLE BY hrappserver ON BEHALF OF ANY;
This auditing option only audits SELECT statements being initiated by hrappserver on behalf of other users. A DBA can enable separate auditing options to capture SELECTs against the bonus table from clients connecting directly to the database:
AUDIT SELECT TABLE.
For audit actions taken on behalf of the real user, you cannot audit CONNECT ON BEHALF OF DN, since the distinguished name is not known to the database. However, if the user accesses a shared schema (for example, APPUSER), then you can audit CONNECT ON BEHALF OF APPUSER.
Many applications use session pooling to set up a number of sessions to be reused by multiple users. In this context, "application users" are users who are authenticated to the middle tier of an application, but who are not known to the database. Oracle9i supports application user proxy for these types of applications.
In this model, the middle tier passes a client identifier to the database upon the session establishment. (The client identifier could actually be anything that represents a client connecting to the middle tier; a cookie, for example, or an IP address.) The client identifier, representing the application user, is available in user session information and can also be accessed via an application context (via the USERENV naming context). In this way, applications can set up and reuse sessions, while still being able to keep track of the "application user" in the session. Applications can reset the client identifier and thus reuse the session for a different user, enabling high performance. For OCI-based connections, alteration of the CLIENT_IDENTIFIER is piggybacked on the other OCI calls to further enhance performance. Application user proxy is available in thin JDBC, thick JDBC, and OCI, and provides the benefits of connection pooling without the overhead of separate user sessions (even lightweight ones).
Application user proxy can be used with global application context for additional flexibility and high performance in building applications. For example, suppose a web-based application that provides information to business partners has a notion of three types of users: gold partner, silver partner, or bronze partner representing the different levels of information available. It is not important to the application that users be known to the database, but it needs to limit data access based on contexts representing gold partner, silver partner, or bronze partner respectively. That is, instead of each user having his own session--with the individual application context set up--the application could set up global application contexts for gold partner, silver partner, or bronze partner and use the client identifier to point the session at the correct context, in order to retrieve the appropriate type of data. The application need only initialize the three global contexts, and use the client identifier to access the correct application context to limit data access. This provides performance improvements through session reuse, and through accessing global application contexts set up once, instead of having to initialize application contexts for each session individually.
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|
