![]() |
![]() |
|
|
Security and CORBA Server Applications
This chapter discusses security and CORBA 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 CORBA Server Applications
Generally, CORBA server applications have little to do with security. Security in the BEA Tuxedo 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 BEA Tuxedo system make any requirements on server applications running in the BEA Tuxedo domain.
However, there may be occasions when implementing or enhancing a security model in your CORBA 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 BEA Tuxedo domain, see Creating CORBA Client Applications. For information about implementing a security model in the BEA Tuxedo domain, see Setting Up a BEA Tuxedo Application.
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 BEA Tuxedo domain (note that the student user of the application provides only the username and 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 BEA Tuxedo domain.
Note: The get_student_details() operation has nothing to do with implementing a security model in the BEA Tuxedo 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
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 BEA Tuxedo 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:
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 BEA Tuxedo 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;
};
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|