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.
- Agree to accept the CA's certificate for this session only.
- Select "Request a Personal Certificate" from the menu.
- A form will be displayed in which you enter the components of
your Distinguished Name. These may include: Organization Name, and
Organization Unit, common name and email address. The form
may have fixed values for some of the components or allow you
to choose from a menu.
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.