A User's Guide to Akenti Security

Mary Thompson and Srilekha Mudumbai


Akenti security is implemented by servers which use the SSL protocol to manage resources which have been protected by use-condition certificates created by the owners of the resources. In order to get access to a protected resource, a user must present an identity certificate issued by an acceptable certificate authority (CA) to the secure server. This certificate is used to get access to the secure server and may be further used to prove that the user meets the use-conditions imposed by the resource owner. In addition, a resource owner may require that a user possess attribute certificates, which attest to characteristics other than the user's identity (a level of training, a position within an organization, etc.).

One secure server that we have implemented is the SSL-patched version of the Apache Web server, with an added Akenti policy module. The user contacts this server through a standard Web browser using URLs that begin with https: rather than http:.

We have also implemented a secure ORB (ORBIX 2.3 with ORBIX-SSL). The user accessing this ORB must handle his identity certificates himself.

There are currently three different ways for a user to figure out if he has access to a resource. Access to these scripts/applets may be restricted in the future to increase the security of the system. But meanwhile they allow a stakeholder to get an clear view of what policy applies to his resource, and a user who is being denied access to a resource to figure out what conditions he is not satisfying.

Getting an Identity Certificate

In order to use an Akenti-secured Web server, the user needs to get an identity certificate and install it in his Netscape browser.The browser will then present it when he references the secure Web server. Note that the protocol https rather than http is used when contacting either the CA or a secure Web server. The procedure to get a personal identity certificate from a Netscape CA is as follows: Open https://CA_hostName where CA_hostName is the host on which the CA runs. Your Netscape browser will generate a private/public key pair. You may choose a key size. Key sizes of 512 bits have been broken. So far, key sizes of 1024 have not. Your private key will be stored in .netscape.key3.db. You should have a password set for that database. It can be set or reset using the Security/Password menu of Communicator. This is the Communicator .db password that is asked for when you first present a certificate to a server.

After the CA administrator has processed the request a URL will be mailed back to you from which you can retrieve the certificate. Your Netscape 4.x browser will tell you the name of the certificate and let you define a nickname for it. It will then store it in .netscape/cert7.db. You are also given a chance to store the certificate and private key someplace external to the Communicator database. It could be on a floppy disk. You will need to pick a passphrase that will be used to encrypt your certificate. This passphrase will be used if you ever want to import this certificate back to a different web browser. This certificate will now show up in the list of "your certificates" under the Netscape "security" menu item.

The Netscape browser has lots of options you can set under the "security" toolbar button, e.g., which certificate to use, how often to ask for a password, etc.

Whenever you access a Web server with the https protocol, your browser will send along your identity certificate.

Accepting the CA as a recognized authority

If you are going to use a secure server or CA regularly, it is a good idea to register the CA with your browser. This keeps the browser from complaining about an "unknown Certificate Authority" each time it receives a certificate signed by this CA. To accept the CA as a "signer" go back to the https://CA_hostName, go to the Retrival tab and then click on "Import CA Certificate Chain". Once you have completed this step, the CA should show up in the list of signers off of the security menu.

Showing the policy for a resource

show-policy is a script that will show all the policy files (.htauthority) that apply to a resource. It also displays all the use-conditions to which the policy files point. This tool gives stakeholders a chance to see what use-conditions other stakeholder for shared resources have imposed. Since policy files are hierarchical, even if there is only one stakeholder for a given level, use-conditions applied at a higher level may affect a resource.

See the specification for the authority files and use-conditions to understand how to interpret the output. Note that a use-condition will only apply to a resource lower in the hierarchy if the scope is "sub-tree" and that a user must satisfy any use-condition that as the word "access" in the enable line.

To use this script either get to it from the resource server home page Show Policy menu or call it directly as:

https://<hostname>/cgi-bin/show-policy?resource=<resource-name>

Monitoring an access attempt

The Monitor applet, available from the resource server home page, allows a user to watch the steps of an attempted access as it is happening. To use this applet, you start with the introductory page and select which version of the applet you want to run. Both versions use features of JDK 1.1 and the Java swing classes. Only versions 4.06, 4.5 and later of Netscape support JDK1.1. Earlier versions need the JDK 1.1 plug-in available from SunSoft. The plug-in includes the swing classes as well, which means that using the plug-in version even in the later versions of Netscape, reduces the startup time for the applet by the amount of time it takes to down-load the 1.6M-byte swing.jar file. Both versions of the applet are identical except in the way they are run by the browser.

Having selected either version of the applet, it brings up its main window. You now need to connect to the server, giving the common name part of the identity certificate you are using as your login name.

Clicking on the "connect to server" button brings up the following login screen.

Type in your common name. In the example I used Mary R. Thompson. This name is case sensitive and must exactly match what is in your identity certificate. You can use the security/certificates/yours/view menu to see your identity certificate.

Now to back to your main browser page and make a reference to a resource on the secure server. The applet main window will display one line for each resource the request needed. The resource name will be underlined in green if the access succeeded and in red if it did not.

Clicking on a resource name brings up a window with more detail about the access. Each dot represents a step in the access checking process. Gray dots are lookups, green dots represent successful outcomes, yellow dots represent non-fatal failures, and a red dot represent a failure that results in denying access to the resource.

Clicking on a dot will bring up a window with a textual explanation of what the event is. The following window shows a use-condition that has been added to the conditions that must be satisfied.

Displaying the access log

display-access is a script that will make an access to the specified resource and return a pointer to the Akenti Log segment for that access. This functionality has been re-implemented in a more user friendly fashion by the monitor applet. This script remains mostly as a quicker way for a knowledgeable user or stakeholder to check an access. One difference from the Monitor Applet is that the display-access script turns off caching for the duration of the access, so you will always see the worst case for gathering and verifying of certificates.

To use this script either use the Display access menu on the resource server's home page or call it directly by:

https://<hostname>/cgi-bin/display-access?resource=<resource_name>
Click on the "LogFile" link to see the raw log file for your access.