Integrating Akenti Access Control into a CORBA server

Overview
Requirements
Configuring your environment
Preparing your servers
Generating Use Conditions

Overview

      Akenti  has been integrated with  Iona's  commercial C++ based ORB,  Orbix .  The OMG defined interceptor layer is used to intercept incoming requests to a CORBA server.  The request is evaluated by Akenti first, if it satisfies all policy constraints the request is passed to the server, and invocation proceeds as normal.  If the requestor is unable to to satisfy the policy constraints, the request is denied, and the server is never invoked.

    To use Akenti to provide access control to CORBA servers, you must first configure the environment correctly for Akenti.  Then Akenti must be added to the filter chain of all servers that Akenti will be protecting.  Before either can be done, there is a question that  must be answered.  At what level of granularity will access control be provided?  In particular, will you be protecting not only servers, and methods on those servers, but individual objects?  Note:  this decision can be made on a per server basis.

    The following diagram illustrates the overall architecture of an Orbix installation that is using SSL over IIOP.










Requirements

  1. Version 3.0, or later of Orbix.  (It must offer support for Filters)  Currently the only supported platform is Solaris 2.5+.
  2.  OrbixSSL is required to provide an authenticated communication channel.  Client authentication must be used, because Akenti requires an authenticated client certificate to make access decisions.
  3. Akenti has been installed, and the shared libraries built on your system.  See  An Administrator's Guide to Akenti  for more information on this process.
Configuring your Environment
  1. Create a shadow directory structure that maps to the directory structure in your Implementation Repository.  For each node in the repository that you wish to protect, create an equivalently named directory in your shadow tree.  If you wish to control access to individual objects, each object will need a directory entry in this shadow tree.  In practice this means devising a scheme to create directory entries dynamically, and place the appropriate policy files there.  The root node of this tree will be referred to as the root of the resource tree.  This shadow tree will be where you place the policy files ( description of the policy files ) Akenti will use to make access decisions for the related resource.  For example: 
  2. Now you must decide what to call the root node of your resource tree.  Since this name will appear in all use conditions issued for your resources, it should uniquely identify your installation.  For example, we have been using LBL as our root node name.
  3. Now create a symbolic link from your root node name to the root of your resource tree.  This is needed to allow the policy engine to locate the top of the resource tree.
        ln -s /absolute_path_to/resource_root RootNodeName
  4. Add the appropriate policy files to the shadow directory.  For an example of a .htauthority file see:   http://www-itg.lbl.gov/Akenti/AuthorityFile.html
  5. At run-time Akenti must be able to locate its configuration file. (Akenti.conf) The environment variable AKENTI_CONFIG is used to point to the absolute location of Akenti.conf.  In csh do: setenv AKENTI_CONFIG /absolute_path/to/Akenti.conf.  It is important to note that, since Orbix servers get their environment from orbixd, this variable must be set in the environment that is used to start orbixd.
  6. The location of the Akenti libraries must be added to your LD_LIBRARY_PATH.  As with the preceding step, this variable must be set in the environment used to start orbixd.
Preparing your servers.

    After configuring the environment properly, and getting the appropriate policy files,  the servers must now be prepared to use Akenti.  Assuming an already working Corba server that is using OrbixSSL for its communications, this step is easy.  The first  line of your server's main function should instantiate an automatic variable of type AkentiFilter or AkentiFilterPerOb.  AkentiFilerPerOb is used if you wish to control access to individual objects.  Assuming a standard installation of Akenti, this code should be located under the installation root in src/libsrc/CORBAFilters/.   At compile time you will need access to all of the code in this directory.  (ActionsCache.cc, ActionsCache.h, AkentiFilter.cc, AkentiFilter.h, AkentiFilterPerOb.cc, AkentiFilterPerOb.h, DN_util.cc, DN_util.h, RSAPrivKey_util.cc, RSAPrivKey_util.h)  The appropriate header must be included also.  This is either AkentiFilter.h, or AkentiFilterPerOb.h.  The following code snippet shows the beginning of the main method of a generic Corba server.

#include "AkentiFilterPerOb.h"
#include <IT_SSL.h>

extern char *optarg;
extern int optind;

int main (int argc, char* const* argv) {
   AkentiFilterPerOb myFilter;
  int ret;
  if ((ret = OrbixSSL.init())!= IT_SSL_SUCCESS) {
       if (ret == IT_SSL_ERR_SECURITY_INACTIVE) {
           cerr << "SSL is not active!" << endl;
      } else
           cerr << OrbixSSL.getInitErrorString() << endl;
       return 1;
   }
   OrbixSSL.setClientAuthentication(1);

This simple addition is the only necessary change to your server to use Akenti for access control.

Generating Use Conditions.

  To be able to generate  Use Conditions  for a resource,  a  Resource Definition server  must be running on the machine with the ORB.  This server listens for incoming http requests, and returns information from the resource tree to the certificate generators.  When generating a Use Condition, the resource name you should enter is http://MachineName/RootNodeName/Server.  For example, our machine name is george, our RootNodeName is LBL, and we have a server Foo.  The resource name used in the Use Condition generator is http://george.lbl.gov/LBL/Foo.  For more information on generating Use Conditions see:   http://www-itg.lbl.gov/Akenti/docs/stakeholder.html