Previous     Contents     DocHome     Index     Next     
Portal Server Plug-in for the Identrus System 2.0 Installation, Administration & User Guide



Chapter 2   Administration


Administering the iPlanet Portal Server Plug-in for the Identrus System involves setting up appropriate certificates that allow authentication and authorisation of Identrus member users. The objectives of this chapter are to cover:


Administrator Login Procedure

  • From your browser select the url to the Portal Server. Normally this will be http://<machine name>:<port>/console. For example: http://firestorm.jcp.co.uk:8080/console

Figure 2-1    Administrator Login Screen

  • Login to the Portal Administrator account and the following screen appears:

Figure 2-2    Administration Main menu

  • Select <Manage Identrus Plug-in> On first occurrence, this jumps to the Trusted Certificate Store Password Screen. Enter the password you wish to use to gain access to the certificate store. This should be the same password as for your PKCS11 token password (see section on "HSM Configuration"). This only applies if you are using an external HSM.

Figure 2-3    Certificate Store Password

  • Select <Next> Here you should make your RDB settings as illustrated below:

Figure 2-4    RDB Settings

  • The following settings are required:

    • <Connection URL> i.e. the location of your oracle database.

    • <Username> i.e. the username to allow you access onto the oracle framework database

    • <Password> i.e. the password to allow you access onto the Oracle framework database.

    • <PBE Password> i.e. the password that allows you access to the encrypted data held within the certificate Storage locations running within the Oracle database.

  • Select <Next> when you have finished making your selections

  • In all subsequent occurrences, when selecting <Manage Identrus Plug-in>, the following menu appears:

Figure 2-5    iPlanet Portal Server Plug-in for the Identrus System Main Menu Options

After explaining the different procedures for obtaining certificates, we then discuss these choices in turn:

  • <Generate Identrus Certificate> for certificates requiring verification

  • <Login Authorisation>, <Netmail> decide who can use the system and also how they can use the system.

  • <CSC Configuration>, <RC Host>, <Certificate Status>

  • <SSL Communication> allowing transport authentication


    Note All configuration options should be considered in turn and when you have finished making your configuration selections scroll down to the bottom right hand corner and press

    to make your selections take effect.



Generating Identrus Certificates

The following Certificates are used for signing purposes, allowing integrity and avoiding email messages that have been tampered with, and as such require a PKCS10 request from the Identrus system and a PKCS7 Response from your CA:

  • Request Signing Certificate

  • Response Signing Certificate

  • SSL Client Certificate signs the handshake request.

All other Certificates are needed for validation/verification purposes, allowing authentication and authorisation, and should be obtained directly from your CA:

  • Trusted Login CA Certificate

  • Trusted Email Certificate

  • Trusted Response Verification Certificate


    Note How the Certificate Authority sets this procedure up will depend on its security policy. If in doubt you should give this to your CA operator who will process it and return a Certificate back to you.



Adding a Certificate for Authentication and Authorisation purposes

In this case a PKCS10 request is not needed and as such the following procedure applies:

  • From the iPlanet Portal Server main screen, select <Manage Identrus Plug-in>

Figure 2-6    Portal Administrator Main Screen

  • Select <CSC Configuration>, Select <Add>, for example <Trusted Response Verification certificate> as illustrated below:

Figure 2-7    CSC Configuration

  • Certificates can be added by pasting in a certificate you obtained directly from your CA.

Figure 2-8    Pasting a base64 encoded certificate into your iPlanet Portal Server Plug-in for the Identrus System


Adding a Certificate for Signature purposes

There are two main steps to this (Generating a signature request using a PKCS 10 Request from the Identrus System and getting a PKCS 7 Response from your Certificate authority):

  • From the main Menu Select <Generate Identrus Certificate>:

Figure 2-9    Portal Administrator Main Screen

  • The following Certificate Settings must be supplied:

Figure 2-10    Generating a PKCS#10 certificate request

  • <Key length> (choice of 512 bit, 1024 bit).

  • <Common Name> is the Name to give the certificate e.g. Portal SSL Certificate.

  • <Organisation> the affiliation to which the user creating the certificate belongs e.g. iPlanet.

  • <Organisational Unit> that represents the department or subsidiary of the organisation to which the user/entity belongs.

  • <Country> that the user is based, as defined as ISO3611 standard http://www.iso.ch and X500 standard http://www.itu.int/itudoc/itu-t/rec/x/x500up/x500.html e.g. GB.

  • Generate a certificate request by selecting

    This will cause a certificate request to be made. The request will be a base64 encoded PKCS 10 request.

Figure 2-11    Copying a PKCS10 request

  • Go to a CA Web-site and search for the section that involves creating a Server Certificate and follow the instructions until it asks you to paste in the PKCS10 request.

Figure 2-12    Paste PKCS10 Request into CA Website

  • Collect the corresponding base64 encoded certificate response using cut and paste. When copying and pasting certificates use <Ctrl>C <Ctrl>V.

Figure 2-13    Copy base64 encoded Certificate response from CA

  • From iPlanet Portal Server main screen, select <Manage Identrus Plug-in>

  • Select <CSC Configuration>

  • Now Select <Add> from the diagram below

Figure 2-14    CSC Configuration

  • Certificates can be added by pasting in the resulting base64 encoded PKCS 7 response.

Figure 2-15    Pasting a base64 encoded Certificate response

  • Select <Add>

  • Alternatively the import feature,

    illustrated on the previous page, allows you to enter a PKCS7 response as a filename.


Removing a Certificate

Certificates can also be removed and in such cases will render users unable to send validated messages.


Note If in doubt, please consult your local product support representative on how to install your Certificate.



Login Authorisation


This option allows you to decide what login security measures you want in place for your users when they log in. Allowed settings are:

  • Never check certificate status at login

  • Always check certificate status at login

  • Check certificate status only at first login

  • Positive certificate status checks are cached for the period (in minutes) given. If the user subsequently logs in within the cache period then the previously requested status is used. Note that negative (revoked/unknown) responses are not cached.

Figure 2-16    Login Authorisation Main Choices

Enter the certificate of the Relying Participant's bank here. Any customers of this particular Identrus member bank can login to the Portal Sever. Trusted certificates can be added or removed accordingly. One or more base64-encoded certificates may be pasted into the configuration interface. For an identity certificate presented at login to be considered part of the scheme, one of these certificates must appear in its certificate chain.


Note In order to obtain this certificate you should contact your CA administrator who, because you are already an Identrus member, will be in possession of both the Identrus root certificate and your relying participants certificate. If in doubt, please consult your local product support representative on how to install your Certificate. See also Section "Adding a Certificate for Authentication and Authorisation purposes".



Netmail Configuration


For billing reasons there are a number of scenarios for deciding whether you wish a Certificate Status check done automatically or manually. In the case where most of your users are known, Certificate Status Checks may not be necessary. There are three choices:

  • Automatically perform CSC Check

  • Allow Manual User checks

  • Allow non-scheme certificate signature checks. If true then non-scheme signatures are checked and the relevant icon displayed; otherwise no signature checks are performed on messages signed by a non-scheme certificate.

Figure 2-17    Netmail Configuration Options

Enter the Identrus root certificate here. Any email sent by any Identrus member can be verified. Other base64-encoded certificates may be pasted into this configuration interface. For an email-signing certificate to be considered part of the scheme, one of these certificates must appear in its certificate chain.

In order to obtain this certificate you should contact your CA administrator who, because you are already an Identrus member, will be in possession of both the Identrus root certificate and your relying participants certificate.


Note If in doubt, please consult your local product support representative on how to install your Certificate. See also "Adding a Certificate for Authentication and Authorisation purposes".



CSC Configuration


A Certificate Status Check allows you to check the status of any Identrus member certificate. The OCSP or Identrus CSC responder either responds to these requests by contacting its local responder, if this organisation issued a certificate or it forwards the request to another Responder whose organisation issued the certificate.

Figure 2-18    Example Identrus CSC Illustrating certificates needed to generate and verify messages

Before adding the Request/Response certificates, you will need to make sure the root certificate and its corresponding CA check has been configured. If you have the Certificate as an individual base64 encoded certificate it is recommended you add the root then <replace> it with the CA and then replace again with the corresponding Request and Response certificate. This has the effect of configuring the full Root/CA/Request or Response Certificate chain.

Figure 2-19    CSC Configuration

The following certificates need to be configured in order for users to perform Certificate Status Checks.

  • Request Signing Certificate. The signing key for CSC requests (sent from the RC host to RP) is held in a Hardware Security Module (HSM). All private key operations involving the signing key take place on the HSM. See Section "Adding a Certificate for Signature purposes" on how to obtain this)

  • Response Signing Certificate. The signing key for CSC responses (sent from the RC host to RC) is also held in a Hardware Security Module (HSM). Again, all private key operations involving the signing key take place on the HSM. See "Adding a Certificate for Signature purposes" on how to obtain this)

  • Trusted Response verification certificates. One or more base64-encoded certificates may be pasted into the configuration interface. For an OCSP responder or CSC responder to be trusted, one of these certificates must appear in the responder's certificate chain. (See Section "Adding a Certificate for Authentication and Authorisation purposes"). This can be either a Certificate Authority that acts as an OCSP responder (e.g. the VA certificate) or in the case of Identrus the Relying Participant End Entity Signing certificate as illustrated in Figure 2-19.


    Note If in doubt, please consult your local product support representative on how to install your Certificate. Before adding a Certificate you must get your certificate from an appropriate authority. See Section "Generating Identrus Certificates" for details on how to do this.



RC Host Configuration

The following Relying Customer (RC) settings must be made:

  • Responder types. There are two choices here: a) OCSP if you want to use an OCSP Responder. b) Identrus Certificate Status Check if you have a full Identrus implementation.

  • Responder URLs e.g. `https://hailstorm.uk.sun.com:8080.

  • The OCSP Requestor name. The name of the entity making an OCSP request needed when signed (usually a URL).

Figure 2-20    RC Host Configuration


Certificate Status


These settings define the system and whether or not Certificate Status Checks can be made for the system as a whole. They also define the database connection information used by the iPlanet Portal Server Plug-in for the Identrus System. Administrators wishing to view a Certificate Status Check made via the system will need to consult the audit log, see section "Logging".

  • Enable Certificate Status Checks.

Figure 2-21    Certificate Status Configuration

The following settings are required:

  • <Connection URL> i.e. the location of your Oracle database.

  • <Username> i.e. the username to allow you access onto the Oracle framework database

  • <Password> i.e. the password to allow you access onto the Oracle framework database.

  • <PBE Password> i.e. the password that allows you access to the encrypted data held within the certificate Storage locations running within the Oracle database.


SSL Communication

Certificates are required at the transport layer in order to allow SSL Handshaking to take place. The following Certificate options are needed:

Figure 2-22    SSL Communication Configuration

In order to obtain this certificate you should contact your CA administrator who, because you are already an Identrus member, will be in possession of both the Identrus root certificate and your relying participants certificate.


Logging



Configuration

The log can either be enabled or disabled. If the log is disabled then no new entries will be recorded in the view.

Figure 2-23    Configuring Logging


Viewing

From the main menu, Select <Logging> allows you to view aspects of the log.

Figure 2-24    Logging Main Menu

  • A number of error logs can be viewed. By selecting your server e.g. firestorm.jcp.co.uk

  • If you see the message "readExceedsMax" Error then the log file is too big to view on the screen. The files are still, however, viewable and can be found at the Portal default log directory
    /var/opt/SUNWips/logs

Figure 2-25    Example Server log files

There is an option also to delete specific log files if necessary. We now describe these log files.

  • <iwtAuthentication>. Records all logon attempts, whether successful or failed. For the latter, the reason for logon failure will also be logged.

  • <iwtGateway>. This is part of the standard Portal Server log and as such you should consult the Portal Administrator's guide for details about this.

  • <iwtAdmin>. This is part of the standard Portal Server log and as such you should consult the Portal Administrator's guide for details about this.

  • <iacMessageLog>. All certificate status check messages sent and received by the system are logged. Specifically, this includes:

    • CSC request received from RC

    • CSC request sent to RP

    • CSC response received from RP

    • CSC response sent to RC

  • The following fields are included in the log record:

    • The raw message - this is always timestamped and signed by one of the RC, RC Host or CSC responder.

    • Requesting User - this allows determination of volume and type of request per requestor for profiling.

    • Subscribing Customer Certificate Chain

    • Date & Time - recorded to the nearest second. Timestamp format is YYYYMMDDhhmmss.

    • URL of responder - although the responder URL is fixed for the system for the time being, we log it in anticipation of a requirement to support multiple responders or if it changes over time.

    • Response Status - success, failure (with a record of the specific business or technical error causing the transaction's failure), timeout etc.

    • Certificate Status - valid, revoked, unknown.

    • Transaction ID

    • Complete response message

    • Context of request (currently mail check/login)

  • <iacMessageLog-1> When a log file grows too large, it is renamed, and a new log file started in its place. This is a renamed iacMessageLog

  • <iwtNetMail> This is part of the NetMail log and as such you should consult the Portal Administrator's guide for details about this.

  • <iacAppLog> All errors are logged to an error log - this includes business, technical and implementation errors. The log entry includes

    • Date & Time - recorded to the nearest second. Timestamp format is YYYYMMDDhhmmss.

    • A unique identifier allowing the exact line of source code to be pinpointed.

    • A description of the error.

    • Data associated with the error where appropriate (e.g. a host name in the event of a connection failure)

    • Some kinds of errors may include a call-stack of any Java Exceptions


      Note In some instances more information may be required. Under such circumstances, these logs are also expressed as text files that can be found in the following directory /var/opt/SUNWips/logs.



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

Last Updated May 16, 2001