Authentication

The Oracle data server is a secure server; a client application cannot access data stored in the database without first being authenticated by the database server. Oracle8i CORBA server objects and Enterprise JavaBeans execute in the database server. For a client to activate such an object, and invoke methods on it, three conditions must be satisfied:

1. The client must be able to authenticate itself to the server, by passing a valid database username and the correct password for that username. (A database role can also be passed to the server along with the username and password.)

2. The client must have access rights to any object that it activates. This means that a published object must have been published so that it can be executed either by PUBLIC, or by the client user(name) activating it. It also means that the classes that implement the published object must have been loaded into the database with the appropriate access rights.

3. In some cases, the client must have execute privileges on the method itself. For example, an EJB deployment descriptor can be written to establish access rights on a method-by-method basis.

This section describes client authentication techniques, because it is the client that must authenticate itself to the database when a new session is started. When a CORBA server object or an EJB starts a new session, it is acting just like a client for authentication purposes.

It is important to remember that each new connection must be authenticated by the server. A typical example where this is required is when a client passes an object reference (a CORBA IOR or an EJB bean handle) to a second client. The second client then tries to connect to the session specified in the object reference. The second client must also authenticate itself to the server. This can be done in several ways, using either credentials over SSL or the login protocol. See the examples "sharedsession", or "saveHandle".

Basic Client Authentication Techniques

There are three ways that a client can authenticate itself to the server:

1. Use the Oracle8i login protocol over a standard (not secure socket layer) TCP/IP transport connection.

2. Use the login protocol over a secure socket layer connection.

3. Use credential-based authentication over a secure socket layer (SSL) connection.

Each of these authentication techniques is secure. In the first case, the Oracle8i login protocol makes sure that the password is passed from the client to the server in encrypted form, even if the remainder of the client-server communication is passed in the clear. In the second and third cases the password is encrypted by the SSL transport.

The authentication technique that the client uses is determined by the value that is set in the javax.naming.Context.SECURITY_AUTHENTICATION attribute when the JNDI initial context is established. There are four possibilities:

• ServiceCtx.NON_SSL_LOGIN establishes use of the Oracle8i login protocol when the transport is not SSL.

• ServiceCtx.SSL_LOGIN specifies use of the login protocol over an SSL connection.

• ServiceCtx.SSL_CREDENTIAL specifies use of the credential protocol over an SSL transport. In this protocol the password is not encrypted above and beyond the encryption provided by SSL, and it so might be slightly more efficient than SSL_LOGIN, in which the added encryption is redundant.

• Nothing is specified. In this case, it is necessary for the client to activate the login protocol directly before it can activate and invoke methods on a server-side object.

  This case is frequently used when a client needs to connect to an existing session, and invoke methods on an existing object. See "sharedsession" for an example.

  In this case, it is also not necessary to specify the username and password in the initial context environment, as they will be passed as parameters to the login object's authenticate() method.

The Login Protocol

A client can use the login protocol to authenticate itself to the Oracle8i data server. You can use the login protocol either with or without SSL encryption, since a secure handshaking encryption protocol is built in to the Oracle8i ORB login protocol.

Establishing the Login Protocol

If your application requires an SSL connection for client-server-client data security, then specify the SSL_LOGIN service context value for the SECURITY_AUTHENTICATION property that is passed when the JNDI initial context is obtained. For example:

Hashtable env = new Hashtable();
env.put(javax.naming.Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
env.put(javax.naming.Context.SECURITY_PRINCIPAL, username);
env.put(javax.naming.Context.SECURITY_CREDENTIALS, password);
env.put(javax.naming.Context.SECURITY_AUTHENTICATION, ServiceCtx.SSL_LOGIN);
Context ic = new InitialContext(env);
...

See "Using the Secure Socket Layer" for more information about SSL connections.

If your application does not use an SSL connection, then specify NON_SSL_LOGIN as follows:

...
env.put(javax.naming.Context.SECURITY_AUTHENTICATION, ServiceCtx.NON_SSL_LOGIN);
...

In this case, the login handshaking is secured by encryption, but the remainder of the client-server interaction might be less secure.

When you specify values for all four JNDI Context variables (URL_PKG_PREFIXES, SECURITY_PRINCIPAL, SECURITY_CREDENTIALS, and SECURITY_AUTHENTICATION), then the first invocation of the Context.lookup() method performs a login automatically.

The Login protocol requires two components: a client component and a server component. The client component, Login, serves as an implementation of the client side of the login handshaking protocol and as a proxy object for calling the server login object. The client component is packaged in the aurora_client.jar file. Oracle8i ORB applications must always import this library.

Credentials

Using the ServiceCtx.SSL_CREDENTIAL authentication type means that the username, password, and role (if specified) are passed to the server on the first request (method invocation).

Because this information is passed over an SSL connection, the password is effectively encrypted by the transfer protocol, and there is no need for the handshaking that the Login protocol uses. For that reason, the credential protocol is slightly more efficient, and is recommended for SSL connections.

---