Security Hompage
![]() ![]() ![]() |
Overview
Requirements
Configuring your environment
Preparing your servers
Generating Use Conditions
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.
ln -s /absolute_path_to/resource_root
RootNodeName
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. 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 #include "AkentiFilterPerOb.h"
extern char *optarg;
int main (int argc, char* const*
argv) {
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 <IT_SSL.h>
extern int optind;
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.
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