Previous     Contents     DocHome     Index     Next     
iPlanet Trustbase Transaction Manager 2.2.1 Installation and Configuration Guide



Chapter 4   Authorisation


Authorisation revolves around the idea of authenticating a service by assigning a role that can authenticate aspects of a service by linking a certificate to a role. Each certificate is assigned a distinguished name and a role that can authenticate to any number of levels down a certificate hierarchy.


Introduction



The iPlanet Trustbase Transaction Manager authorisation facilities provide the operator with the ability to prevent unknown users accessing services. The authorisation management screens allow the operator to modify the set of known users, and the services they are allowed to access. Changes in the authorisation screens modify the iPlanet Trustbase Transaction Manager authorisation database and are made immediately.

The iPlanet Trustbase Transaction Manager will perform an authorisation check on every request that starts a new user session e.g. when the operator logs on to the system or when a CSC is received. This check maps a username or certificate to a role, and this role is passed around the system with the request. Prior to the router invoking a service the authorisation database is checked to see which roles are allowed to access the service. If the roles match then the operation is allowed. If there is a mismatch then the router will log an authorisation failure and the request will be rejected.

All of the facilities required to organise the authorisation parameters are accessible from the main authorisation menu shown below.

Figure 4-1    Authorisation Main Menu



Authorising users to access a service



Authorising users for a particular service is a multistage process. The steps are:

  • Define a role - Create a group under which the users will be identified

  • Add users to the role - Identify the individuals that will be members for the group

  • Map the role to the service - Provide an authorisation to use a service if they hold a particular role

  • Allocate a certificate to each role.

The following sections describe this process in more detail.


Defining a role

Selecting <Add role> from the main menu will provide a form that contains the following:

  • Name - The text label for the new role

  • Description - Free text description of the role. This is not used by the authorisation mechanisms, but is useful for describing the use of a particular role

  • Active - Unchecked means the router will throw an unauthorised response even if the role to service link is correct.

Submitting the form will update the authorisation tables immediately. After adding a new role, using the view role option from the authorisation menu will contain the updates immediately. The view roles option on the main menu allows the operator to select an existing role and modify the original values. By default the iPlanet Trustbase Transaction Manager has three pre-set roles that map to specific users.

Figure 4-2    List of default Roles


  • Administrator This role allows Administration access to all configuration screens.

  • NoRole - This is a role that is not active and is currently for internal use only. It is a holder for assigning "items" no role.

  • Identrus - This role allows access to Identrus Services. At present there is one main service IdentrusCSCService that performs certificate status checks and forms the basis of all Validation, verification, integrity and authentication.



    Note The iPlanet Trustbase Transaction Manager contains a default Role 'NoRole'. This is used internally by the iPlanet Trustbase Transaction Manager Services and should not be modified of removed.




Adding users to roles

Users may be identified in one of two ways:

  • Username and Password

  • Certificate

The username and password authorisation is generally used for operational management of the iPlanet Trustbase Transaction Manager. This allows operators to log onto the systems and interact with the management screens as shown in this manual.

Figure 4-3    Add New User


New usernames can be added using the <New user> button on the Authorisation home page. The following input is required for each user:

  • Username

  • Password

  • Role - This is only from the selection of existing roles

A number of users may be added prior to submitting the form. Once a set of users have been added they immediately become active in the Authorisation tables and are capable of using the role assigned to them.


Adding a Certificate

Certificate authentication is used for Identrus messages, and before a third party may interact with the iPlanet Trustbase Transaction Manager they must have the certificate details entered in the Authorisation system. iPlanet Trustbase Transaction Manager removes the need to enter every known certificate in the Authorisation table by allowing the use of parent certificates in lieu of the actual certificate.

Figure 4-4    Identrus PKI hierarchy

In the Identrus PKI hierarchy the End Entity Identity certificates issued by the Level 1 CA are used by the Relying Customer to sign requests to the iPlanet Trustbase Transaction Manager. The Level 1 Transaction Manager Inter-Participant Signing Certificate is used to sign requests made between the various iPlanet Trustbase Transaction Managers during a certificate status check.

The complete set of Identrus operations may be authorised by placing a single certificate in the authorisation system. This certificate is the Identrus Root CA Certificate. This Root CA certificate must be entered with a Maximum Depth value of 2. This indicates that certificates issued up to 2 levels below the Root CA certificate i.e. The Level 1 Transaction Manager End Entity Signing Certificate, and the Inter-Participant Signing Certificate(s) will be mapped onto the same Role as the Identrus Root CA certificate.

To add an authorisation based on a certificate select <Add Certificates> on the Authorisation main page. The form presented requires the following information for each certificate:

  • Issuer DN - This field is case sensitive and DN information entered in the incorrect case will case an authorisation failure for the certificate.

  • Serial Number

  • Maximum depth - Maximum length of the chain between this certificate and the child certificate capable of using this role.

  • Role - Selected from the list of previously defined roles

  • Access - Toggle on for this certificate to be active

Figure 4-5    Adding a Certificate


The active toggle allows the operator to explicitly override an inherited authorisation. This means that a parent certificate may be used to authorise a large number of issued certificates except those that have an explicit entry in the Authorisation table with the Access toggle off. This mechanism is useful in situations where a certificate requires suspension for a period of time prior to the CA revoking it.


Mapping roles to Services

Having created a role and mapped a set of users to the role the final step is to define the set of services that may be accessed using the role.

Each service is capable of being accessed by a single role. This requires some design and thought to the authorisation mappings prior to modifying an existing authorisation mechanism. By default the iPlanet Trustbase Transaction Manager contains an existing set of role to service mappings that allow the following:

  • Operators to configure the installation using the configuration facilities described in this guide. This maps onto the "Administrator" role name.

  • Holders of End Entity Certificates to access the approved set of Identrus service subject to mapping the certificate details onto the "Identrus" role.

To map a new service to a role select new service on the Authorisation main menu. The form requires the following information:

  • Service name - The short name of the service found in the tbase.properties file

  • Role - The name of the role

A number of service to role mappings may be added to the list at the bottom of the form prior to submitting the form. Once the mappings have been submitted to the authorisation database they are effective immediately.

To modify an existing service to role mapping, select the edit services from the Authorisation main menu. This presents a list of the entire role to service mapping database for inspection. Selecting the Modify link on a particular item in the list will allow the details of the specific entry to be updated.

Figure 4-6    Services to role mapping list



Previous     Contents     DocHome     Index     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated April 18, 2001