Release 2 (8.1.6)
A81356-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Enterprise JavaBeans and CORBA Developer's Guide Release 2 (8.1.6) A81356-01 |
|
This chapter describes in detail how both CORBA and EJB clients connect to an Oracle8i server session and how they authenticate themselves to the server. The term client, as used in this chapter, includes client applications and applets running on a network PC or a workstation, as well as distributed objects such as EJBs and CORBA server objects that are calling other distributed server objects and, thus, acting as clients to these objects.
In addition to authentication, this chapter discusses security of access control to objects in the database. A published object in the data server has a set of permissions that determine who can access and modify the object. In addition, classes that are loaded in the data server are loaded into a particular schema, and the person who deploys the classes can control who can use them.
This chapter covers the following topics:
The examples in Chapter 3, "Developing CORBA Applications" and Chapter 2, "Enterprise JavaBeans" showed how to connect to Oracle, start a database server session, and activate a CORBA server object or an EJB, using a single URL specification. In the client examples, connection and object look up was done as follows:
1. Hashtable env = new Hashtable(); 2. env.put(javax.naming.Context.URL_PKG_PREFIXES, "oracle.aurora.jndi"); 3. env.put(javax.naming.Context.SECURITY_PRINCIPAL, username); 4. env.put(javax.naming.Context.SECURITY_CREDENTIALS, password); 5. env.put(javax.naming.Context.SECURITY_AUTHENTICATION,
ServiceCtx.NON_SSL_LOGIN); 6. Context ic = new InitialContext(env); 7. myHello hello = (myHello) ic.lookup("sess_iiop://localhost:2481:ORCL/test/myHello"); 8. System.out.println(hello.helloWorld());
In this example, there are four basic operations:
In line 7 above, when a client looks up an object, the client and server are doing a lot of things automatically:
lookup() invocation, a session IIOP connection is made to the ORCL instance of the local host database.
/test/myHelloServer in the session name space.
/test/myHello.
When the object reference is returned, the client can invoke a method such as helloWorld() on the activated, narrowed object, as in line 8 above. This example shows a CORBA server object being looked up and activated, but a similar set of steps, including the narrowing, occurs when an EJB is activated through its home interface.
The remainder of this chapter describes the connection, service and session context establishment, and authentication steps. Code examples are provided to demonstrate how to control session invocation in a much finer-grained way than in the basic example above.
This chapter also describes different types of client authentication in addition to the NON_SSL_LOGIN method that the basic examples use. This chapter also discusses other aspects of security.
In addition to authentication and privacy, Oracle8i supports controlled access to the classes that make up CORBA and EJB objects. Only users or roles that have been granted execute rights to the Java class of an object stored in the database can activate the object and invoke methods on it.
You can control execute rights on Java classes with the following tools:
-grant argument to loadjava. See the Oracle8i Java Developer's Guide for more information about loadjava and execution rights on Java classes in the database.
SQL> GRANT EXECUTE ON "Hello" TO OTTO;
Use the SQL command REVOKE EXECUTE to remove execute rights for a user from a loaded Java class.
You can control permissions on a published object in two ways:
Use the ls -l command in the session shell to view the permissions (EXECUTE, READ, and WRITE) and the owner of a published object.
There are three "built-in" server objects that a client can access without being authenticated, as shown below:
You can activate these objects using serviceCtx.lookup() without authentication. See "explicit" for an example that access the Login object explicitly.
In networking, the presentation layer is responsible for making sure that data is represented in a format that the application and session layers can accommodate. In Oracle, presentation can refer to a service protocol that accepts incoming network requests and activates routines in the database kernel layer or in the Java VM to process the requests.
Earlier versions of the Oracle database server had a single service--the two-task common (TTC) layer. This is the service that processes incoming Net8 requests for database SQL services from Oracle tools (such as SQL*Plus), and customer-written applications (using Forms, Pro*C, or the OCI).
In addition to TTC support, Oracle8i JServer supplies session IIOP service, implemented by the class oracle.aurora.server.SGiopServer, which handles TCP/IP requests routed to the service entrypoint by the listener and dispatcher. The IIOP service is capable of starting, controlling, and terminating Oracle8i database sessions, in the same way that an incoming TTC request from a tool such as SQL*Plus is capable of starting and terminating a database session.
When using the Oracle8i JServer tools, especially when developing EJB and CORBA applications, it is very important to distinguish the two service types: TTC and IIOP.
Tools such as publish, deployejb, and the session shell access CORBA objects, and so must connect using an IIOP port. In addition, EJB and CORBA clients, or distributed objects acting in a client role, must use an IIOP port when sending requests to Oracle.
On the other hand, tools such as loadjava and dropjava connect using a TTC port.
Figure 4-1 shows which tools and requests use TTC and which use IIOP database ports. 1521 is the default port number for TTC, and 2481 is the default for IIOP.
The session IIOP service embeds a session identifier in object references. This allows a single client to access multiple sessions, which would be impossible if there were no concept of a session identifier in object references.
The session IIOP service uses the foundation provided by the Oracle8i multi-threaded server to provide very high application scalability. See the Oracle8i Java Developer's Guide for introductory information about application design and scalability. IIOP is discussed in greater detail in "About the Session IIOP Protocol".
Clients use the Java Naming and Directory Interface (JNDI) interface to look up published objects in the session name space. JNDI is an interface supplied by Sun Microsystems that gives the Java application developer a way to access name and directory services. In addition to the API used by the application developer, some of whose classes and methods are described in this section, there is also a JNDI Service Provider Interface (SPI). Oracle8i JServer has implemented a SPI to the OMG CosNaming service, which provides the access to the published object name space.
This section discusses only those parts of the JNDI API that are needed to look up and activate published objects. To obtain a complete set of documentation for JNDI, see the web site URL http://java.sun.com/products/jndi/index.html.
When you use JNDI in your client or server object implementations, be sure to include the following import statements in each source file:
import javax.naming.Context; // the JNDI Context interface import javax.naming.InitialContext; import oracle.aurora.jndi.sess_iiop.ServiceCtx; // JNDI property constants import java.util.Hashtable; // hashtable for the initial context environment
It is also possible to access the session name space without using JNDI. See "Using Certificates for Client Authentication" for a Java example that does not use JNDI.
Context is an interface in the javax.naming package. All Oracle8i EJB and CORBA clients that use JNDI methods to look up and activate server objects must import this interface.
The javax.naming.Context interface forms the basis for the JNDI operations that you use to manage services and sessions in the Oracle8i ORB. This class is fully documented in the standard JNDI javadoc from Sun Microsystems. See http://java.sun.com/products/jndi/index.htm to obtain this documentation.
This section documents only the Context variables and methods that are most frequently used in Oracle8i CORBA and EJB application development.
Before you can use JNDI to connect your client program to an Oracle8i server, you must set up an environment for the JNDI context. You can use a hash table or a properties list for the environment. The examples in this guide always use a Java Hashtable, as follows:
Hashtable environment = new Hashtable();
Next, you set up properties in the hash table. You must always set the Context URL_PKG_PREFIXES property. The remaining properties that you can set are for authentication. They are:
javax.naming.Context.SECURITY_PRINCIPAL
javax.naming.Context.SECURITY_CREDENTIALS
javax.naming.Context.SECURITY_ROLE
javax.naming.Context.SECURITY_AUTHENTICATION
Context.URL_PKG_PREFIXES holds the name of the environment property for specifying the list of package prefixes to use when loading in URL context factories. The value of the property should be a colon-separated list of package prefixes for the class name of the factory class that will create a URL context factory.
In the current implementation, you must always supply this property in the Context environment, and it must be set to the String "oracle.aurora.jndi".
Context.SECURITY_PRINCIPAL holds the database username.
Context.SECURITY_CREDENTIAL holds the clear-text password. This is the Oracle database password for the SECURITY_PRINCIPAL (the database user). In all of the three authentication methods mentioned in SECURITY_AUTHENTICATION below, the password is encrypted when it is transmitted to the server.
Context.SECURITY_ROLE holds the Oracle8i database role with which the user is connecting. For example, "CLERK" or "MANAGER".
Context.SECURITY_AUTHENTICATION holds the name of the environment property that specifies the type of authentication to use. Values for this property provide for the authentication types supported by Oracle8i. There are four possible values, which are defined in the ServiceCtx class:
ServiceCtx.NON_SSL_LOGIN: The client authenticates itself to the server with a username and password using the Login protocol over a standard TCP/IP connection (not a secure socket layer connection). The Login protocol provides for encryption of the password as it is transmitted from the client to the server. The server does not authenticate itself to the client. See "Providing Username and Password for Client-Side Authentication" for more information about this protocol.
ServiceCtx.SSL_CREDENTIAL: The client authenticates itself to the server providing a username and password that are encrypted over a secure socket layer (SSL) connection. The server authenticates itself to the client by providing credentials.
SSL_LOGIN: The client authenticates itself to the server with a username and password within the Login protocol, over an SSL connection. The server does not authenticate itself to the client.
See "Configuring CORBA and EJB in JServer" for more information about configuration.
The Context interface contains a number of methods that the CORBA and EJB application developer will use. The methods required have been implemented in the ServiceCtx and SessionCtx classes that implement methods in the Context interface.
InitialContext is a class in the javax.naming package that implements the Context interface. All naming operations are relative to a context. The initial context implements the Context interface and provides the starting point for resolution of names.
You construct a new initial context using the constructor:
public InitialContext(Hashtable environment)
passing it a hashtable that has the environment information described in "Connecting Using JNDI" above. The following code fragment sets up an environment for a typical client, and creates a new initial context:
Hashtable env = new Hashtable(); env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi"); env.put(Context.SECURITY_PRINCIPAL, "scott"); env.put(Context.SECURITY_CREDENTIALS, "tiger"); env.put(Context.SECURITY_AUTHENTICATION, ServiceCtx.NON_SSL_LOGIN); Context ic = new InitialContext(env);
This is the most common initial context class method that the CORBA or EJB application developer will use:
public Object lookup(String URL)
You use lookup() to create a new service context, specifying in the URL the service identifier. The return result must be cast to ServiceCtx when a new service context is being created. For example, if initContext is a JNDI initial context, the following statement creates a new service context:
ServiceCtx service = (ServiceCtx) initContext.lookup("sess_iiop://localhost:2481:ORCL");
This section describes the Oracle8i IIOP services, session IIOP, and the use of the Oracle8i session for EJB and CORBA applications.
The industry-standard CORBA does not support the concept of sessions, but the session concept is fundamental to the Oracle8i database and the JServer ORB. Because objects are activated within a session, the ORB and the database need a means to be able to distinguish objects within the same server process based on the sessions in which they are activated. You can activate objects within the existing session or another session. Session IIOP service provides a way for applications and server objects to distinguish sessions as well as services.
The session IIOP service introduces a new component tag, SessionIIOP, inside the IIOP profile (TAG_INTERNET_IOP--the OMG component tag for Oracle session IIOP is 0x4f524100). The session IIOP component tag has information that uniquely identifies the session in which the object was activated. The client ORB runtime uses this information to send requests to objects in a particular session.
Although the Oracle8i session IIOP service provides an enhancement of the standard IIOP protocol--it includes session ID information--it does not differ from standard IIOP in its on-the-wire data transfer protocol.
Clients must have an ORB implementation that supports session IIOP to be able to access objects in different sessions simultaneously, from within the same program, and to be able to disconnect from and reconnect to the same session. The version of the Visigenic ORB that ships with Oracle8i has been extended to support session IIOP, and discussions are underway for other ORB vendors to support it as well.
When a client makes an IIOP connection to the database, the server code must decide if a new session should be started to handle the request, or if the request should be routed to an existing session. If the client initializes a new request for a connection (using the InitialContext.lookup() method) and no session is active for that connection, a new session is automatically started.
With session IIOP the server is able to decide, on the basis of the object being activated, whether to activate a new session or route to an existing session, depending on the absence or presence of a session ID component tag inside the IIOP profile.
Clients access EJB and CORBA applications in the database over an Internet Inter-Orb Protocol (IIOP) connection. IIOP is an implementation of General Inter-Orb Protocol (GIOP) over TCP/IP. All IIOP connections for CORBA or EJB clients that communicate with the database must have IIOP configured on the database and within the Net8 listener.
The database supports incoming requests through a presentation. The presentation protocol is responsible for making sure data is represented in a format the application and session layers can accommodate. Both the listener and the dispatcher accept incoming network requests based upon the presentation that is configured. For IIOP, you configure a GIOP presentation.
|
Note: For security concerns, you must decide if your IIOP connection will be Security Socket Layer (SSL) enabled.
|
The configuration for an IIOP connection can be handled in one of three ways:
initjvm.sql script, you must manually configure your IIOP connection. All configuration is done manually either by invoking the Database Configuration and Net8 Assistants directly or by editing the various initialization parameter files.
During a Typical installation of the server, JServer is installed and configured for you. You automatically receive configuration for an MTS database with session-based IIOP connections through the listener using non-SSL TCP/IP.
After the typical install is complete, the following line is added to your database initialization file:
mts_dispatchers="(protocol=tcp)(presentation=oracle.aurora.server.SGiopServer)"
If, instead, you installed the Advanced Security Option and you want the SSL-based TCP/IP connection, edit your database initialization file to remove the hash mark (#) from the following line:
mts_dispatchers="(protocol=tcps)(presentation=oracle.aurora.server.SGiopServer)"
In addition, the listener is configured for IIOP. The following is placed within your listener.ora file:
listener=
(description_list =
(description=
(address=(...)
(protocol_stack=
(presentation=GIOP))
(session=RAW)
)
)
After configuration, the client directs its request to a URL that includes the host and port, which identifies the listener, and either the SID or database service name, which identifies the database. The following shows the syntax for this request:
session_iiop://<hostname>/:<portnumber>/:<SID |service_name>
If, within a Custom install, you choose the JServer option (as shown in Figure 4-2), the Database Configuration Assistant configures an MTS database for session-based IIOP connections, using non-SSL TCP/IP.
|
Note: If you choose the Typical or Minimal options within the custom choices, your configuration is the same as defined in "Oracle8i Typical or Minimal Installation". |
This places the following line within your database initialization file:
mts_dispatchers="(protocol=tcp)(presentation=oracle.aurora.server.SGiopServer)"
If, instead, you installed the Advanced Security Option and you want the SSL-based TCP/IP connection, edit your database initialization file to remove the hash mark (#) from the following line:
mts_dispatchers="(protocol=tcps)(presentation=oracle.aurora.server.SGiopServer)"
After the installation is complete, you must bring up the Net8 Assistant to configure the listener for IIOP connections.
The Net8 Assistant can modify any of the listener settings. The following is a brief description of the task you must do to configure the listener through the Net8 Assistant. For a fuller explanation, see the Net8 Administrator's Guide.
This brings you to the listener location panel, as shown in Figure 4-3.
This places the following within your listener.ora file:
listener=
(description_list =
(description=
(address=(protocol=tcp)(host=sales-server)(port=2481))))
(protocol_stack=
(presentation=GIOP))
(session=RAW)
)
)
After configuration, the client directs its request to a URL that includes the host and port, which identifies the listener, and either the SID or database service name, which identifies the database. The following shows the syntax for this request:
session_iiop://<hostname>/:<portnumber>/:<SID |service_name>
If you did not install JServer through either the Typical or Custom install options, you can add JServer to an existing database with the initjvm.sql script. See the Oracle8i Java Developer's Guide for more information on this script.
Once you have installed JServer, you can configure your IIOP connections either through the tools--Database Configuration and Net8 Assistants--or by manually editing the initialization files.
dbassist at $ORACLE_HOME/bin.
After starting up the Database Configuration Assistant, choose the JServer option. For information on what this does to your initialization files, see "Oracle8i Custom Installation"
The presentation layer within the database identifies the type of connection your client is using to access the database. To identify the GIOP presentation, you use oracle.aurora.server.SGiopServer, which is the configuration for session-based IIOP connections. EJB and CORBA applications can activate objects within multiple sessions and are not limited to objects within the single session that the client initiated. These connections identify both a session and the standard IIOP semantics.
To configure an IIOP connection, you specify the GIOP presentation in the following initialization files:
This section describes only the PRESENTATION attribute for the MTS_DISPATCHERS parameter. For a full description of MTS configuration, see the Net8 Administrator's Guide.
Both steps are described in more detail below.
To configure an IIOP connection within the database, you can manually edit the database initialization file.
The following is the syntax for the MTS_DISPATCHERS parameter:
mts_dispatchers="(protocol=tcp | tcps)
(presentation=oracle.aurora.server.SGiopServer)"
The attributes for MTS_DISPATCHER are described below:
For example, to configure MTS for session-based IIOP connections through the listener using non-SSL TCP/IP, add the following within your database initialization file:
mts_dispatchers="(protocol=tcp)(presentation=oracle.aurora.server.SGiopServer)"
Each listener is configured to listen on a well-known port number, and the client communicates with the listener using this port number. To support CORBA and EJB, the listener must be configured to listen for IIOP clients on either ports 2481 or 2482.
You can either use the Net8 Assistant to configure your listener or manually configure the listener within the listener.ora file. Oracle recommends that you use the Net8 Assistant. See "Net8 Assistant" for information on the Net8 Assistant.
To configure the listener manually, you must modify the listener's DESCRIPTION parameter within the listener.ora file.
You must configure the listener with a GIOP listening address. The following example configures a GIOP presentation for non-SSL TCP/IP with port number 2481. You use port 2481 for non-SSL and port 2482 for SSL.
For GIOP, the PROTOCOL_STACK parameter is added to the DESCRIPTION when configuring an IIOP connection to sales-server:
listener= (description_list= (description= (address=(protocol=tcp)(host=sales-server)(port=2481)) (protocol_stack= (presentation=giop) (session=raw))))
The following table gives the definition for each of the GIOP parameters:
If you want your client to go to a dispatcher directly, bypassing the listener, you direct your client to the dispatcher's port number. Do one of the following to discover the dispatcher's port number:
lsnrctl service.
If you choose to configure the port number, the following shows the syntax:
mts_dispatchers="(address=(protocol=tcp | tcps)
(host=<server_host>)(port=<port>))
(presentation=oracle.aurora.server.SGiopServer)"
The attributes are described below:
The client supplies the port number on its URL, as follows:
session_iiop://<hostname>/:<portnumber>
Notice that the URL excludes a SID or service name. The dispatcher does not need the SID instance or service name because it is a directed request.
Oracle8i also supports the use of authentication data such as certificates and private keys required for use by SSL in combination with GIOP. To configure your transport to be SSL-enabled with GIOP, do the following:
The following sections detail how to accomplish these three steps.
You must edit the database initialization file to add an SSL-enabled dispatcher. Uncomment the MTS_DISPATCHERS parameter in the database initialization file that defines the TCPS port. During installation, the Database Configuration Assistant always includes a commented out line for SSL TCP/IP. This line is as follows:
mts_dispatchers="(protocol=tcps)(presentation=oracle.aurora.server.SGiopServer)"
Modify the listener to accept SSL requests on port 2482.
This brings you to the listening port panel, as shown in Figure 4-4.
These steps will add wallet and SSL configuration information into both the listener and database configuration files. The SSL wallet location must be specified in both the listener and database configuration files. Both entities must locate the wallet for certificate handshake capabilities.
listener.ora file: ssl_client_authentication=false ssl_version=undetermined
The default is for the database to authenticate the client. If you want the listener to authenticate the client, change the ssl_client_authentication parameter to true.
sqlnet.ora file: ssl_client_authentication=true ssl_version=0 sqlnet.crypto_seed=<seed_info>
If you did not request client authentication, the ssl_client_authentication parameter will be false. The default value is for client authentication to be true. In addition, you can specify a specific SSL version number, such as 3.0, in the ssl_version parameter. The ssl_version value of 0 means that the version is undetermined and will be agreed upon during handshake.
listener.ora and database's sqlnet.ora files, the wallet location is specified:oss.source.my_wallet=(source= (method=file) (method_data= (directory=wallet_location)))
The Oracle Advanced Security Administrator's Guide describes how to set up the SSL wallet with the appropriate certificates.
This brings you to the listener location panel, as shown in Figure 4-3.
This places the following in the listener.ora file: it modifies the listener to specify TCPS --instead of TCP--as the protocol with port number 2482. The following shows an example of an SSL-enabled listener on the sales-server host.
listener= (description_list= (description= (address=(protocol=tcps)(host=sales-server)(port=2482)))) (protocol_stack= (presentation=giop) (session=raw)))
When the listener receives a request for an IIOP connection from a client, it assigns an IIOP dispatcher to the client request, and sends an IIOP reply to ask the client to reconnect to the dispatcher. Figure 4-6 shows the interaction between the listener and the dispatchers, and also illustrates how an Oracle8i ORB session is activated.
When a shared server services a new IIOP connection, it first creates a new database session for it and activates the ORB in the session. This session is very similar to the database sessions created for incoming Net8 connections. In the session, the ORB reads the incoming IIOP messages, authenticates the client, finds and activates the corresponding server-side objects, and sends IIOP messages as needed to reply to the connected client.
Further IIOP messages from the same client are routed directly to the existing session and handled similarly by the ORB.
When you configure a listener to accept both Net8 and IIOP connections, there is no need to distinguish between session IIOP and "standard" IIOP. The listener handles both on the same port. However, you do need a separate port for secure socket layer (SSL) connections. See "Using the Secure Socket Layer" for more information about connecting using IIOP and SSL.
Oracle8i provides universal resource locator (URL) syntax to access services and sessions. The URL lets you use JNDI requests to start up services and sessions, and also to access components published in the database instance. An example service URL is shown in Figure 4-7.
The service URL is composed of four components:
myPC-1. You can also use localhost or the numeric form of the IP address for the host.
ORCL--or the service name--for example, mySID.myDomain.
service_name or the db_name.db_domain parameters defined in your database initialization file. If you use the service name within your service URL, the listener will load balance incoming requests across multiple database instances: that is, all database instances registered with the listener. This options is good when you are using parallel servers.
Always use colons to separate the hostname, port, and SID or service name.
When you make a connection to Oracle and look up a published object using JNDI, you use a URL that specifies the service (service name, host, port, and SID), as well as the name of a published object to look up and activate. For example, a complete URL could look like:
sess_iiop://localhost:2481:ORCL/:default/projectAurora/Plans816/getPlans
where sess_iiop://localhost:2481:ORCL specifies the service name, :default indicates the default session (when a session has already been established), /projectAurora/Plans816 specifies a directory path in the name space, and getPlans is the name of a published object to look up.
Each component of the URL represents a Java class. For example, the service name is represented by a ServiceCtx class instance, the session by a SessionCtx instance. (See the ORB JavaDoc on the distribution CD for detailed documentation of these classes. The most relevant methods and variables are also described below.)
Oracle provides a service context class that extends the JNDI Context class.
The ServiceCtx class defines a number of final public static variables that you can use to define environment properties and other variables. Table 4-1 shows these.
This section documents the public methods in this class that CORBA and EJB application developers can use.
public Context createSubcontext(String name)
This method takes a Java String as the parameter and returns a JNDI Context object representing a session in the database. The method creates a new named session. The parameter is the name of the session to be created, which must start with a colon (:).
The return result should be cast to a SessionCtx object.
Throws javax.naming.NamingException.
public Context createSubcontext(Name name)
(Each of the methods that takes a String parameter has a corresponding method that takes a Name parameter. The functionality is the same.)
public static org.omg.CORBA.ORB init(String username, String password, String role, boolean ssl, java.util.Properties props)
Gets access to the ORB created when you perform a look up. Set the ssl parameter to true for SSL authentication. Clients that do not use JNDI to access server objects should use this method.
See "sharedsession" for a usage example.
public synchronized SessionCtx login()
login() authenticates the caller using the properties in the initial context environment and then activates a new session and returns the session context. The returned object is narrowed to the appropriate type.
Throws javax.naming.NamingException.
public Object lookup(String string)
lookup() looks up a published object in the database instance associated with the service context, and either returns an activated instance of the object, or throws javax.naming.NamingException.
public Object _lookup(String string)
_lookup() looks up a published object in the database instance associated with the service context and either returns the object, or throws javax.naming.NamingException. Unlike with lookup(), the object is not activated.
Oracle provides a session context class, SessionCtx, that extends the JNDI Context class. Session contexts represent sessions and contain methods that enable you to perform session operations such as authenticating the client to the session or activating objects.
The session context methods that a client uses are the following:
public synchronized boolean login()
login() authenticates the client using the initial context environment properties passed in the InitialContext constructor: username, password, and role.
public synchronized boolean login(String username,
String password,
String role)
login() authenticates the client using the username, password, and optional database role supplied as parameters.
public Object activate(String name)
Looks up and activates a published object having the name.
