CONTROL

SINCE CONTROL CURRENTLY STRICKLY USES ORBAsec SL2, IT HAS BEEN RETIRED

Simple CORBA Security Access Control

CONTROL is an ORB that performs Authentication and Simple Automatic Access Control for CORBA objects.

CONTROL uses Standard CORBA Security

CONTROL is built on top of ORBAsec SL2, which is an implementation the Standard CORBA Security Security Level 2 Service.

CONTROL has ORB services that offer:

GUI and Text based Authenticators for Kerberos and SSL
Access Control Interceptor for Target Objects
Server Access Manager Object for Dynamic Access Policy Updating

CONTROL invents and makes use of the concepts of:

SAL, an Access Control Language (paper)
Hierarchical Object Domains
Object Owners
Domain Owners

Other client based tools are provided with CONTROL for administering security policy.

Tool for Checking SAL Syntax
Tool for Administering SAL Policy Updates to a Server.

Open Source!

CONTROL comes with full source code! CONTROL extends ORBAsec SL2, which is also an Adiron Open Source Product. That gives you, the developer, the ability to study, debug, and enhance certain CONTROL features. CONTROL mandates the use of OBX, (Adiron's Extensions to the ORBacus ORB). OBX extends the ORBacus ORB with a rudimentary interceptor feature and a couple of other things to make CONTROL work.

How does each CONTROL Server Work?

Each Server starts up with a call to its configuration file. This file specifies configuration parameters needed to initialize the underlying CONTROL, ORBAsec SL2, and ORBacus libraries. Initialization of CONTROL requires that one principal is authenticated through one of its authenticators. Authentication, depending on the version of ORBAsec SL2 that you have, authentication can be performed for a Kerberos identity, SSL identity(X.509 Certificate Chain), or just plain old IIOP.

The Authenticators are directed via the configuration file, and can be configured to ask for authentication information in both GUI and text based forms. Also, you can examine the code, see how it is done, and create your own authenticators with your own GUIs or text!

After initialization, the authenticated Credentials are used for the Credentials of any object connected to the server's ORB instance. Those Credentials are also used for any invocation the object makes. At the initialization of the BOA, CONTROL installs an AccessManager as an initial service and installs the access control interceptor. The object reference of this AccessManager object gets published according to its initialization specification. This object reference is the key to updating the server's access policy.

The call returns from the CONTROL initialization routine, and the code is free to connect object implementations to the ORB using the BOA and calling orb.impl_is_ready().

How does an CONTROL Client Work?

A CONTROL Client initializes itself much the same way as the Server does, except that it does not require that a BOA be initialized, and therefore, no access control is performed and no AccessManager exists.

What is required for CONTROL?

CONTROL is a Java based product built on top of Adiron's ORBAsec SL2, which provides authentication verification and request protection in the form of encrypted and integrity protected requests. CONTROL requires a developer license for ORBAsec SL2. CONTROL also requires ORBacus from Object Oriented Concepts, Inc., as well as the JDK from Sun Microsystems, Inc. You also need an authentication infrastructure. This can be a Kerberos or DCE KDC with its administration tools, or a Certificate Authority that provides certificates. ORBAsec SL2-SSL even provides some tools for generating X.509 Certificates using the IAIK JCE Toolkit.

How easy is CONTROL to Use?

Terribly easy. The standard code for a server is the same for every ORB:

public class Server {
  public static void main(String[] args) {
    org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,new java.util.Properties());
    orb.BOA_init(args,new java.util.Properties());
    org.omg.CORBA.Object obj = new MyObjectImpl();
    orb.connect(obj);
    orb.impl_is_ready(null);
  }
}

with a CLASSPATH (JDK 1.1) or -Xbootclasspath (JDK 1.2) of

Control.jar:OBX.jar:SL2.jar:GSSKRB.jar:SSL_IAIK.jar:OB.jar:iaik_full.jar:rt.jar

That's It! Therefore, transitioning an already built application on a standard Java ORB would be a cinch to migrate to CONTROL and add confidentiality, integrity, and access control protection to your objects!

A typical configuration file for an CONTROL based server using a GUI Kerberos Authentication would be as simple as:

# Kerberos GUI Server Authentication
control.authentication=kerberos
control.authentication=kerberos.auth_method=pwgui
control.authentication=kerberos.usage=AcceptOnly
# AccessManager
control.access.description=FILE:MyAccessPolicy.sal
control.access.AccessManager=FILE:AccessManager.ior

The "FILE:MyAccessPolicy.sal" value tells CONTROL where to find the initial access control policy, which is written in SAL, CONTROL's access policy language.

The "FILE:AccessManager.ior" states that this file will be created with the stringified IOR of the Server's AccessManager object.

Note, also, there may be such other configuration parameters needed in the configuration file such as properties that set the threading model of the ORB.

Is it Really that Easy?

Technically Yes! However, any good application of security takes time and careful thought about your installation, its boundaries, and your enterprise distributed object model. Substantial planning is needed to write the correct security policy, not only to assure that your system is safe, but also to make sure that your system does not break from the addition of security. Writing security policy can be a difficult task.

How is the CONTROL Access Control Administered?

Access Control Policy for a CONTROL Server is initially specified by a configuration file property at initialization time. However, CONTROL has command line tools for updating a security policy of the Server dynamically, i.e. while the server is still running. One tool, ControlAdmin, is for updating the access policy description for a CONTROL Server, and it can be invoked as follows:

java control.tools.ControlAdmin \
         --access-manager FILE:ServerAccessManager.ior \
         --kerberos-pwsupplied bart@MYREALM.COM mypassword \
         --update \
         --description FILE:MyNewAccessPolicy.sal

You can create your own update tool! Any CONTROL Client program can be written to access the server's AccessManager object through its IDL interface. Therefore, any home grown specific configuration programs can be created to manipulate and create security policy servers or collections of servers via these objects. In fact, ControlAdmin is written as a CONTROL Client program.

Contact ADIRON Today for Your Evaluation Copy

Please contact us at sales@adiron.com to inquire about getting an evaluation copy CONTROL, OBX, and ORBAsec SL2.

webmaster@adiron.com

Copyright 1998 Adiron. All Rights Reserved.
"ORBAsec" and "CONTROL" are trademarks of Adiron, LLC.
"Java" is a trademark of Sun Microsystems, Inc. "CORBA" is a trademark of the Object Management Group.
Other names, products and services may be the trademarks or registered trademarks of their respective holders.