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:
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.
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.
The sections that follow explain:
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:
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:
get_student_details()operation on the
Registrarobject, passing a student ID, to obtain information about the student.
Registrarobject scans the database for student information that matches the student ID in the client request.
Registrarobject returns the
struct StudentDetailsto the client application. (If the student enters an ID that does not match the information in the database, the
Registrarobject returns a CORBA exception to the client application.)
StudentDetailsto the client application, the client application displays a personalized welcome message to the student user.
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 has the following OMG IDL definition: