Akenti Server infrastructure

The Akenti server infrastructure consists of Netscape Certificate Authority (CA) servers who issue Personal, Server and Signing Authority x509 Identity Certificates; Netscape Directory Servers (LDAP and LDAP gateway) which store Identity Certificates; a secure Akenti Web server that manages the protected resources, a Monitor server that logs and can display the steps of satisfying an access, a Caching server that caches certificates as they are found for later use, and a Resource Definition server that will provide the Attribute and UseCondition generators with information needed when created certificates.

Netscape Certificate Authority server
Issues Identity Certificates on behalf of a given organization. It should run on a secure machine: one that is running a minimum of network accessible servers, and that has a restricted number of login accounts. The Identity Certificate of the CA must be stored in the policy certificate in the root of a resource tree for Akenti to use it to verify identities. You can get a Netscape CA's certificate by going to the CA's web address and selecting "search for a certificate". If you then give it the Common Name of the CA and do a search, it should find the certificate with serial number 1. Bring up the "details" page and find the PEM version of the certificate. You can cut that from the Web page starting with the BEGIN CERTIFICATE line and ending the END CERTIFICATE and paste it into the Root Policy file on your server.

LDAP server
Stores the Identity Certificates issued by the CAs. The Netscape LDAP servers provide a web gateway server as well as the LDAP protocol. Any user can look up people in LDAP. Privileged users (e.g. Directory Manager) can enter new users. Akenti looks up Identity Certificates via the LDAP protocol, both to verify Identity Certificates that have been presented by web clients and to get public keys to verify signers of Attribute Certificates.

Akenti web server
An Akenti enabled version of the Apache web server can be used to provide Akenti strong access control to any resources that can be accessed as web objects. Accessing such a server (via the https protocol) gets you an encrypted connection and presents your Identity Certificate to the server.Normally this server will be set up to require you to have an Identity Certificate issued by one of a selected set of CAs.

Monitor Server
This is a Java server that listens to all the logging messages generated by the Akenti Policy Engine. All the events are stored in a file to produce an audit trail of resource accesses. In addition the Monitor will respond to request of a Monitor applet to display to the user making the request the steps in the access satisfaction process. This applet has several intended uses. One is general debugging and demonstrating that something is happening. The second is to allow legitimate users and stakeholders to find out why an access that should be permitted is being denied. The problems that can arise include a user not having an attribute for something that a stakeholder requires, one of the distributed servers that store the UseCondition and Attribute Certificates being unavailable and a stakeholder higher up in the hierarchy requiring something that the user is missing. Since Akenti is a system designed to make distributed access control easy enough to be useful, we provide this function even at the expense of allowing someone is not allowed access a chance to find out what would be required to get access. If an installation wants to be more secure and less helpful, it can restrict remote access to the Monitor to users with specified Distinguished Names.

Cache Server
This server caches Identity Certificates and UseCondition Certificates to avoid have to do repeated Web searches. Currently the maximum Cache time for all the certificates needed by a resource it defined in the Policy Certiticate for the resource, so that a stake holder can set it for his resources. The Akenti Policy Engine is a set of library procedures which can be called by servers, but also called from scripts that are run as main programs. Thus the simple solution of a memory cache won't work. The solution that was used was to run an independent Cache server, so that all the instances of Akenti policy requests for a single resource tree could share a cache.

Resource Definition Server
When a stakeholder wants to issue a UseCondition or Attribute certificate he needs various bits of information about what attributes, values and users are known for the resource. The Resource Server gives back in an insecure transaction a list of who is allowed to issue Use Conditions for this resource and who the acceptable CAs are (from the Policy Certificate associated with the resource). It will also list the allowed attributes, values, issuers and actions that have been defined for the resource. (These are stored in a Resource attributes file with the resources to which they apply.) This information is in the nature of hints. When a certificate is presented to Akenti for use it is checked against the current allowed signers. So even if one successfully generates a certificate, it must be validated whenever it is used and may become invalid if the list of allowed signers changes, or may become irrelevant if the defined actions change.