Examples of use of access control lists

* description

This example demonstrates basic access control function. You can limit
hosts and users that are allowed to access to a class, an object or a method.
Refer to Security section of the HORB flyer's guide.

If you need to use ACL with a HORBServer in your standalone program,
see the FAQ page.

There are three examples in this directory.

* How to compile and run

c:> horbc Server.java
c:> horbc -c Client.java

* EXAMPLE1

Before running a HORB server, edit example1.acl. You will find the following
line at the end of lines.

  yourname.password=secret

Change yourname to your name and secret to your secret word such like
banana. If you need encripted password, encrypt passwords in your
program. HORB does just string match.

c:> horb -v -acl example1.acl             (start ORB in another window)
c:> java horb.test.accessControl.Client

The client try to access to the object Server as anonymous user, you and
then administrator. By effect of example1.acl;

1) anonymous user couln't access to the object.
2) you can access to the object but not allowed to access method
   dangerous().
3) administrator is allowed to access the method dangerous().


* EXAMPLE2

Example2 shows use of inheritance(?) of ACL files. It uses three local
ACL files. 

   user.acl             user list for  example2
   department.acl       department ACL for example2
   local.acl            local ACL for example2

Since the horb command can take only one -acl option, we should use
a configuration file.

   example2.conf        HORB Server config file for example2

In this config file, the above three files are specified as ACL files.
HORB server reads an ACL file specified by accessControl[0].name, file
specified by accessControl[1].name, and accessControl[2].name,
in this order. In our example2, user.acl, department.acl, and local.acl. 

Lines are stored in the internal, ACL. If some files have the same key,
the last one replaces the former ones.

c:> horb -v -conf example2.conf             (start ORB in another window)
c:> java horb.test.accessControl.Client

Edit ACL files and try them. Note that line

   accessControl.refreshInterval=3600

in example2.conf specifies that reloading interval of ACL files is 
one hour. If you edit an ACL file and this value is smaller, you
will see the effect of editting without restarting a HORB server.

If you are using Windows 95 or NT, Many connections remain due to a
bug of Java's socket implementation. In such case, set refreshInterval
to zero to stop auto refresh.

You can refresh the internal ACL manually from your program.

     HorbURL url = new HorbURL("horb://hostname/SystemACLMaster");
     ACL acl = new ACL_Proxy(url);
     acl.refresh();

Of course, you need to have access permission to SystemACLMaster.


* EXAMPLE3

The sources of ACL files can be other HORB servers. 

c:> horb -v -conf example3master.conf       
			(start ACL master at port 8885 in another window.)
c:> horb -v -conf example3slave.conf        
			(start ACL slave at port 8887 in yet another window.)
c:> java horb.test.accessControl.Client

Client accesses to the slave server. The second server receives
ACL from the master server.

example3master.conf has the following line.

   ACLMaster=true

And example1.acl has the following lines.

   horb.orb.ACL.host=*
   horb.orb.ACL.user=*
   SystemACLMaster.host=*
   SystemACLMaster.user=*

Those turns ACL master function on in the ACL master server. 
You should limit hosts and users in the real world.


* version

Author: HIRANO Satoshi
Versioin: 1.0

* Classes

   Server.java		simple server class
   Client.java		simple client class

   example1.acl         ACL for example1

   example2.conf        HORB Server config file for example2
   department.acl       department ACL for example2
   user.acl             user list for  example2
   local.acl            local ACL for example2

   example3master.conf  config file for example3
   example3slave.conf   config file for example3
