Security and WebLogic Enterprise Server Applications

 

This chapter discusses security and WebLogic Enterprise server applications, using the Security University sample application as an example. The Security sample application implements a security model that requires student users of the University sample application to be authenticated as part of the application login process.

This topic includes the following sections:

• Overview of Security and WebLogic Enterprise Server Applications

• Design Considerations for the University Server Application

 

---

Overview of Security and WebLogic Enterprise Server Applications

Generally, WebLogic Enterprise server applications have little to do with security. Security in the WebLogic Enterprise domain is specified by the system administrator in the UBBCONFIG file, and client applications are responsible for logging on, or authenticating, to the domain. None of the security models supported in the WebLogic Enterprise system make any requirements on server applications running in the WebLogic Enterprise domain.

However, there may be occasions when implementing or enhancing a security model in your WebLogic Enterprise application involves adding objects, or adding operations to existing objects, that are managed by the server application.

This chapter shows how the University server application is enhanced to add the notion of a student, which is incorporated into the client application as a means to identify, and log in, users of the client application.

For information about how client applications are authenticated into the WebLogic Enterprise domain, see Creating CORBA Client Applications. For information about implementing a security model in the WebLogic Enterprise domain, see the Administration Guide.

 

---

Design Considerations for the University Server Application

The design rationale for the Security University sample application is to require users of the client application to log on before they can do anything. The Security sample application, therefore, needs to define the notion of a user.

To log on to the application, the client application needs to provide the following to the security service in the WebLogic Enterprise domain (note that the student user of the application provides only the user name and application password):

• Client name

• Username

• An application password

The Security sample application adds an operation, get_student_details(), to the Registrar object. This operation enables the client application to obtain information about each student user from the University database after the client application is logged on to the WebLogic Enterprise domain.

Note: The get_student_details() operation has nothing to do with implementing a security model in the WebLogic Enterprise domain. The addition of this operation is only a supplemental feature added to the Security sample application. For details about the security model added to the Security sample application, and how client applications log on to the Security server application, see Creating CORBA Client Applications.

The sections that follow explain:

• How the Security University sample application works

• Design considerations for returning student details to the client application

How the Security University Sample Application Works

To implement the Security sample application, the client application adds a logon dialog with the student end user. This dialog uses the local SecurityCurrent object on the client machine to invoke operations on the PrincipalAuthenticator object, which is part of logging on to access the WebLogic Enterprise domain. After the user authentication process, the client application invokes the get_student_details() operation on the Registrar object to obtain information about each student user.

The University database used in the Security sample application is updated to contain student information in addition to course information, and is shown in the following figure:

The get_student_details() operation accesses the student information portion of the database to obtain student information needed by the client logon operation. The following figure shows the primary objects involved in the Security sample application:

A typical usage scenario of the Security sample application may include the following sequence of events:

1. The client application obtains a reference to the SecurityCurrent object from the Bootstrap object.

2. The client application invokes the SecurityCurrent object to determine the level of security that is required by the WebLogic Enterprise domain.

3. The client application queries the student user for a student ID and the required passwords.

4. The client application authenticates the student by obtaining information about the student from the Authentication Service.

5. If the authentication process is successful, the client application logs on to the WebLogic Enterprise domain.

6. The client application invokes the get_student_details() operation on the Registrar object, passing a student ID, to obtain information about the student.

7. The Registrar object scans the database for student information that matches the student ID in the client request.

8. If there is a match between the student ID provided in the client application request and the student information in the database, the Registrar object returns the struct StudentDetails to the client application. (If the student enters an ID that does not match the information in the database, the Registrar object returns a CORBA exception to the client application.)

9. If the Registrar object returns StudentDetails to the client application, the client application displays a personalized welcome message to the student user.

Design Considerations for Returning Student Details to the Client Application

The client application needs to provide a means by which to log a user on to the WebLogic Enterprise system so that the user can continue to use the University application. To do this, the client application needs an identity for the user. In the Security sample application, this identity is the student ID.

All that is required of the University server application is to return data about a student, based on the student ID, so that the client application can complete the user authentication process. Therefore, the OMG IDL for the Security sample application adds the definition of the get_student_details() operation to the Registrar object. The primary design consideration for the University server application is based on the operational scenario described earlier; namely, that one student interacts with one client application at one time, so there is no need for the server application to deal with a sizable batch of data to implement the get_student_details() operation.

The get_student_details() operation has the following OMG IDL definition:

struct StudentDetails
    {
        StudentId         student_id;
        string            name;
        CourseDetailsList registered_courses;
    };