Using CORBA Request-Level Interceptors

InterceptorSec Sample Interceptors

This topic includes the following sections:

Before trying out the steps described in this chapter, make sure you have completed all the steps described in PersonQuery Sample Application.

How the PersonQuery Sample Interceptors Work

The InterceptorSec sample interceptors show a simple client/server interceptor pair that implement a basic security model. The InterceptorSec client-side interceptor simply logs each client request that is handled by the ORB. The InterceptorSec target-side interceptor implements a simple security mechanism that checks to see whether the user of the client application is authorized to perform the operation in the request.

The InterceptorSec sample interceptors show the client and target interceptor pair initialized through a single initialization function and implemented in a single library. Since a single initialization function is called, the interceptor registration command registers one initialization function and one implementation library.

How the InterceptorSec Target-side Interceptor Works

When the target-side ORB receives a request, the ORB calls the InterceptorSec target-side interceptor and passes the RequestContext and DataInputStream objects from the client request.

The target-side interceptor then does the following to authorize the user of the client application for the operation contained in the request:

The sections that immediately follow discuss interceptor security topics and show code fragments of interest from the InterceptorSec target-side interceptor.

Using the SecurityCurrent Object

Interceptors obtain the SecurityCurrent object from the ORB, not from the Bootstrap object. The SecurityCurrent object available from the ORB has the API that interceptors need for obtaining information about the client.

To obtain the SecurityCurrent object, your interceptors can invoke the resolve_initial_references("SecurityCurrent") operation on the ORB. The interceptor can then narrow the SecurityCurrent reference to a SecurityCurrentLevel1 current.

Obtaining the SecurityCurrent Object

The SecurityCurrent object is available only through the ORB, and this object's primary functionality is to provide CORBA server applications access to attributes related to the client invocation.

The ORB's resolve_initial_references("SecurityCurrent") method provides the interceptor a reference to a SecurityCurrent object from which the interceptor is provided with Level 1 Security functionality. The interceptor can obtain the attributes of the client invocation via the get_attributes method on the SecurityCurrent object, which returns an attribute list to the interceptor. The attribute list contains the attributes that pertain to the user of the client application that performed the invocation being intercepted. The behavior of any and all methods from the CORBA security service is still the same, with the exceptions noted above.

The following C++ code fragment shows obtaining the SecurityCurrent object.

try
        {
            sec_current = m_orb->resolve_initial_references("SecurityCurrent");
        }
        catch (...)
        {
            *m_outfile << 
                    "ERROR: ORB::resolve_initial_references threw exception" 
                    << endl << endl << flush;
            excep_val = new CORBA::UNKNOWN();
            return Interceptors::REPLY_EXCEPTION;
        } 
        if  (CORBA::is_nil(sec_current.in()))
        {
            *m_outfile << "ERROR: No SecurityCurrent present"  
                    << endl << endl << flush;
            excep_val = new CORBA::NO_PERMISSION();
            return Interceptors::REPLY_EXCEPTION;
        }
        
        m_security_current = SecurityLevel1::Current::_narrow(sec_current.in());
        if  (!m_security_current)
        {
            *m_outfile << "ERROR: Couldn't narrow security 
                           current to SecurityLevel1::Current" 
                    << endl << endl << flush;
            excep_val = new CORBA::NO_PERMISSION();
            return Interceptors::REPLY_EXCEPTION;
        }

Creating the List of User Attributes

The code fragments in this section show how the InterceptorSec target-side interceptor creates a list of user attributes and then walks through this list to determine if the user matches the authorization criteria.

In the InterceptorSec sample, creating the list of attributes, then walking through them are done in separate steps. Note that if you specify a client attribute list length of zero (0) to be returned, the SecurityCurrent object returns all the attributes for the client.

// Get the attributes that correspond to the information that we need to
// do an authorization check:
//      PrimaryGroupId (clientname of the logged in client)
//      AccessId (username of the logged in client)
Security::AttributeList_var client_attr = 0;
try
{
           client_attr = m_security_current->get_attributes(*m_attributes_to_get);

The following fragment shows creating the list:

   Security::AttributeTypeList_var attr = new Security::AttributeTypeList(2);
    if (!attr.ptr())
    {
        cout << 
                "ERROR: can't allocation security list: Out of memory" 
                << endl << endl << flush;
        return;
    }
    attr.inout().length(2);
    attr[(CORBA::ULong)0].attribute_family.family_definer = 0;
    attr[(CORBA::ULong)0].attribute_family.family = 1;
    attr[(CORBA::ULong)0].attribute_type = Security::PrimaryGroupId;
    attr[(CORBA::ULong)1].attribute_family.family_definer = 0;
    attr[(CORBA::ULong)1].attribute_family.family = 1;
    attr[(CORBA::ULong)1].attribute_type = Security::AccessId;
    m_attributes_to_get = attr._retn();
    return;

The following fragment shows walking through the attribute list to check whether the user matches the authorization criteria:

if  (client_attr[i].attribute_type.attribute_type == Security::PrimaryGroupId)
           {
               //
               // This attribute is the client name.
               // Compare to some client name value.
               // For this example, we're going to accept anything with
               // an 'r' in it, or a NULL string.  You will want to compare
               // the client name to some set of values you have authorized.
               //
               if  ((strlen(value_buffer) == 0) ||
                    (strchr(value_buffer, 'r') != 0))
               { 
                   *m_outfile << "    INFO: Valid client name found: " 
                              << value_buffer << endl;
                   clientname_ok = 1;
               }
               else
               {
                   *m_outfile << "    ERROR: Invalid client name found: " 
                           << value_buffer << endl;
               }
           }
  else if (client_attr[i].attribute_type.attribute_type == Security::AccessId)
           {
               // This attribute is the user name.  We're arbitrarily
               // choosing to authorize anyone who has an 'r', 'n', or 'p'
               // in their user id.  You will likely want to choose
               // some other criteria for authorization.
               //
               if  ((strchr(value_buffer, 'r') != 0) ||
                    (strchr(value_buffer, 'R') != 0) ||
                    (strchr(value_buffer, 'P') != 0) ||
                    (strchr(value_buffer, 'p') != 0) ||
                    (strchr(value_buffer, 'N') != 0) ||
                    (strchr(value_buffer, 'n') != 0))
               {
                   *m_outfile << "    INFO: Valid username found: " 
                              << value_buffer << endl;
                   username_ok = 1;
               }

Registering and Running the PersonQuery Interceptors

When you run the makefile that builds the PersonQuery sample application in PersonQuery Sample Application, the entire set of sample interceptors are built as well, including the InterceptorSec interceptor. This section describes how to register the InterceptorSec interceptor so that it works with PersonQuery application at run time.

To register and run the InterceptorSec client and server interceptors:

Examining the Interceptor Output

The InterceptorSec client and target interceptors log their output to the files named, respectively, InterceptorSecClientxxx.out and InterceptorSecTargetxxx.out. These files contain debugging output from the interceptors that is automatically loaded and executed by the ORB for the PersonQuery application.

Unregistering the Interceptors

After you have run the PersonQuery sample application with the InterceptorSec sample interceptors, you can unregister those interceptors using the following steps: