Security Server Installation and Configuration Guide

SECURITY SERVER INSTALLATION
AND CONFIGURATION GUIDE

Sign&go
Contact
ILEX
51 boulevard Voltaire
92600 Asnières-sur-Seine
Telephone: +33 1 46 88 03 40
Fax: +33 1 46 88 03 41
support@ilex-international.com
www.ilex-international.com
Legal Information
Sign&go is a registered trademark of Ilex. All other trademarks mentioned in this document are the
property of their respective owners.
This document is provided for information purposes only. Ilex provides no guarantee nor accepts any
liability for the information contained in this document. All information and data in this document may
be modified at any time without prior notice.
In accordance with article L. 122-4 of the Code de la Propriété Intellectuelle (French intellectual
property law), any full or partial reproduction, representation or distribution of this document by any
means whatsoever, without the express permission of Ilex, is prohibited and constitutes a breach of
the law that can result in prosecution under Articles L 335 - 2 and subsequent articles of the Code de
la Propriété Intellectuelle (French intellectual property law).
Copyright Ilex 2015. All rights reserved.
Ilex Security server installation and configuration guide Page 2/93

Sign&go
TAB LE OF C ONT EN TS
TABLE OF CONTENTS ....................................................................................... 3

1 FOREWORD ................................................................................................ 5
2 OVERVIEW.................................................................................................. 6
2.1 Composition......................................................................................................... 6
2.2 Installation............................................................................................................ 7
3 INSTALLING THE SIGN&GO SECURITY SERVER ................................................ 8
3.1 Windows 2003 compatibility ............................................................................... 8
3.2 Windows Vista compatibility .............................................................................. 8
3.3 Launching the installer ....................................................................................... 9
3.4 Choice of language ........................................................................................... 10
3.5 Introduction........................................................................................................ 11
3.6 License agreement ............................................................................................ 12
3.7 Product activation key ...................................................................................... 13
3.8 Choice of components ...................................................................................... 14
3.9 Choice of directory ............................................................................................ 17
3.10 Choice of shortcuts ........................................................................................... 18
3.11 LDAP Parameters .............................................................................................. 18
3.12 Servers parameters ........................................................................................... 19
3.14 Installation.......................................................................................................... 24
3.15 Regeneration of keys ........................................................................................ 24
3.16 Installation complete ......................................................................................... 26
4 POST INSTALLATION STEPS ........................................................................ 26
4.1 Starting the servers ........................................................................................... 26
4.2 Sign&go Web administration application ........................................................ 27
4.3 Integrating the administration server with IIS (Windows) .............................. 28
4.4 Integrating the administration server with Apache 1.3 (Windows) ............... 30
4.5 Integrating the administration server with Netscape SuiteSpot (Windows). 32
4.6 Integrating the administration server with IPlanet 6.x (Windows) ................ 33
4.7 Integrating the administration server with Apache 1.3 (UNIX) ...................... 37
5 INITIALISING THE CONFIGURATION DIRECTORY .............................................. 39
5.1 Integration with OpenLDAP .............................................................................. 39
5.2 Integration with Active Directory ..................................................................... 42
Sign&go
5.3 Integration with ADAM ...................................................................................... 44

5.4 Integration with IPlanet Directory Server 4 ..................................................... 45
5.5 Integration with IPlanet Directory Server 5 ..................................................... 47
6 CONFIGURING THE SIGN&GO SECURITY SERVER........................................... 49
6.1 Overview of the installation .............................................................................. 49
6.2 Configuration of the Sign&go administration server ..................................... 51
6.3 Configuration of the security server ................................................................ 53
7 USING THE PRE-CONFIGURED OPENLDAP DIRECTORY ................................. 60
7.1 Access ................................................................................................................ 60
7.2 Generating certificates ...................................................................................... 60
8 SIGN&GO SECURITY SERVER AUDIT MESSAGES ............................................ 70
8.1 Audit information ............................................................................................... 70
8.2 Statistics information ........................................................................................ 78
8.3 Configuration ..................................................................................................... 81
8.4 Modifying the configuration ............................................................................. 89
8.5 Modification to auditing in version 4.3 ............................................................ 90
9 ANNEXES: INSTALLATION OF .WAR FILES ..................................................... 91
9.1 Tomcat 4-5.......................................................................................................... 91

Sign&go
1 FOREWORD
This document is a guide to installing and configuring the Sign&go security server. It describes:
 how to install a Sign&go security server on Windows and Unix platforms,
 how to install the Sign&go administration on Windows and Unix platforms,
 how to install the Sign&go configuration directory in an OpenLDAP, Active Directory or
IPlanet/SunONE directory.
This guide also shows how to modify the Sign&go configuration: listener ports, passwords,
configuration of the LDAP data repository, audit, etc.

Sign&go
2 OVERVIEW
2.1 Composition
Sign&go is a security product which permits strong authentication of users, the implementation of
security policies for access to resources and the deployment of application SSO strategies. These
notions are detailed in the Architecture Guide provided on the Sign&go CD-ROM.
The Sign&go product is composed of two elements:
 the server, management component of the authorisations and authentications, it contains the
security server as well as the product’s administration, user authentication and self-registering
applications,
 the agents, intermediary between the protected resources and the user.
Note: This document concerns the installation and configuration of Sign&go. A separate
document dedicated to the installation and configuration of agents is provided on the Sign&go
CD-ROM, consult this document for more information on Sign&go agents.
The Sign&go server manages the authorisations and authentications of a user on a protected
resource. The configuration of the Sign&go product (configurations, security policies, SSO
strategies…) is saved in an LDAP directory comprising a dedicated directory tree for the Sign&go
data, this is the Sign&go configuration directory.
The Sign&go server equally manages the users, it therefore interacts with the database or directory
that references them, this is the users directory. The Sign&go server is therefore composed of three
elements:
 the security server,
 the configuration directory,
 the users directory.
Note: The configuration directory can be integrated with the users directory. However this
implies that the different trees be managed with differing rights.
The following diagram illustrates these three elements:

Sign&go
2.2 Installation
Installation of the Sign&go server is carried out in two stages:
 installation of the security server,
 installation and configuration of the configuration directory.
The users directory is configured at a later time.
Note: Sign&go connects directly to the company’s user repositories in order to manage the
users and their rights.
2.2.1 Installation of the security server

Refer to the installation chapters of the desired platform for more information:
‘Installing the Sign&go security server’ on page 8.
2.2.2 Installation of the configuration directory

For more information refer to the following chapter:
 ‘Initialising the configuration directory’ on page 39.

Sign&go
3 INSTALLING THE SIGN&GO SECURITY SERVER

Installation of the security server can be carried out in one of two ways:
 In graphical mode on Windows or UNIX type platforms with an X-Windows environment.
 In console mode.
The installation sequence is essentially the same in graphical mode as it is in console mode; this
document will therefore describe them both whilst indicating any differences between them where
necessary.
Installation of the Sign&go security server comprises:
 the Sign&go security server,
 the Sign&go administration server. This is actually the Tomcat 5 Web server including the
Sign&go administration, audit, self-registering and user authentication applications,
 the LDAP server containing the Sign&go configuration data (only on the Windows platform),
 the various administration documentations and APIs.
Note: The screen-captures presented in this document have been made on Windows, however
the installation in graphical mode is the same on Unix.
3.1 Windows 2003 compatibility

From Sign&go version 3.2, the security server installs natively on Windows 2003 and no longer needs
to be installed in ‘compatibility mode‘.
3.2 Windows Vista compatibility

To install the Security Server on Windows Vista, the installation program must be executed in
‘Windows 2000’ compatibility mode:
 Right-Click on the ‘install.exe’ file and select ‘Properties’,
 Click on the ‘Compatibility’ tab,
 In the ‘Compatibility Mode’ section, select the ‘Run this program in compatibility mode for :’ check-
box,
 Select ‘Windows 2000’ from the drop-down list,
 Click ‘OK’,
 Run the file.
In addition, on some systems, ‘Data Execution Prevention’ mode must be de-activated:

 Open the ‘Control Panel’,
 Double-Click the ‘System’ icon,
 Select the ‘Advanced System Settings’ task link in the left hand pane,
 If necessary, click ‘Continue’ on the ‘User Account Control’ dialogue box that appears,
 Select the ‘Advanced’ tab on the ‘System Properties’ dialogue box and click on ‘Settings’ in the
‘Performance’ section,
 Select the ‘Data Execution Prevention’ tab,
 Select the ‘Turn on DEP for all programs and services except those I select’ radio-button,
 Finally, click the ‘Add’ button and browse to the location of the Sign&go Agents installation
program to add it to the list.
Sign&go
3.3 Launching the installer

The various Sign&go installers reside on the CD-Rom in the serveur directory. The installation files in
this directory have the following nomenclature: server_5.0_platformVM where:
platform is one of ‘Windows’, ‘Solaris’, ‘Linux’ or ‘Java’ and indicates the installer’s target operating
system. ‘Java’ indicates any other platform that has a Java virtual machine installed;
VM is either ‘VM‘ or ‘NoVM‘ and indicates whether the installer contains a Java Virtual Machine
(JVM) or not. To carry out an installation on a server that does not have a JVM, the ‘VM’ version of
the installer should be used whereas the ‘NoVM’ should be used for machines that already have a
JVM installed.
Sign&go requires that a JDK be installed on the server. In cases where the target server already has a
JVM installed, it must be at least version 1.5 and the “Java Cryptography Extension (JCE) Unlimited
Strength Jurisdiction Policy Files” must be deployed in the JDK.
3.3.1 Graphical mode

To run the Sign&go installer in graphical mode (on Windows and Linux platforms), simply run the
appropriate binary executable for the platform in question.
3.3.2 Console mode

Operation of the installer in console mode is relatively straightforward:
If default values exist, they are presented in brackets and can be selected by simply pressing ‘Enter’
in response to the question.
To quit the installer, simply type ‘quit’ at anytime.
To return to a previous step in order to re-enter any information, type ‘back’.
To run the installer on a UNIX type platform, enter the installer’s filename at a terminal prompt as
shown below:
cedric@VM-DEB-31-r3:~$ ./server_3.2_LinuxVM.bin
You will then be presented with a screen similar to the following:

Preparing to install...
Extracting the JRE from the installer archive...

Sign&go
Unpacking the JRE...

Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
Launching installer...
Preparing CONSOLE Mode Installation...
3.4 Choice of language

One the installer has started, the first screen allows selection of the language to be used throughout
the rest of the installation process. Only French and English are available at this time. Throughout the
rest of this document, English will be the selected language.
The selected language by default is that of the target operating system.
Select the desired language then click OK.
3.4.2 Console mode

===============================================================================
Choose Locale...
----------------
->1- English
2- Français
CHOOSE LOCALE BY NUMBER:

Sign&go
3.5 Introduction
The following screen presents a brief introduction.
3.5.2 Console mode

===============================================================================ILEX
Sign&go 3.2 - Servers (created with InstallAnywhere by Macrovision)
-------------------------------------------------------------------------------
===============================================================================
Introduction
------------
InstallAnywhere will guide you through the installation of ILEX Sign&go 3.2 –
Servers.
It is strongly recommended that you quit all programs before continuing with this
installation.
Respond to each prompt to proceed to the next step in the installation. If you want
to change something on a previous step, type ’back’.
You may cancel this installation at any time by typing ’quit’.
PRESS <ENTER> TO CONTINUE:

Sign&go
3.6 License agreement

To accept the terms of the license agreement, select “I accept the terms of the license agreement”
then click Next.
3.6.2 Console mode

===============================================================================
License Agreement
------------------
Installation and Use of ILEX Sign&go requires acceptance of the following License
Agreement:
ATTENTION - PLEASE READ THE FOLLOWING LICENSE TERMS AND CONDITIONS CAREFULLY.
THE FOLLOWING LIMITED RIGHTS ARE GRANTED TO YOU:
a. A nonexclusive and non transferrable license, in order to use the number of user
sessions and administration servers specific to your order..
IT IS STRICTLY FORBIDDEN:
a. To modify wholly or partly the program.
b. To decompile or reconstitute the program.
c. For registered users, it is strictly forbidden to transmit their registered

number to a third party.
TO CONTINUE PRESS <ENTER>:

Sign&go
Press Enter as many times as necessary to read the rest of the licence contract.
IF YOU PERFORM ONE OF THESE ABOVE PROCESS, YOUR RIGHTS OF USE ARE AUTOMATICALLY
CANCELLED. THIS CANCELLATION IS ADDED TO THE LEGAL RECOURSE PENAL, CIVIL OR OTHER,
ILEX SYSTÈMES INFORMATIQUES CAN ASSERT.
LIMITED WARRANTY:
NO LIABILITY FOR INDIRECT DAMAGE. ILEX assumes no responsibility in any

circumstance of any damage whatever it may be (including but not in a limited way,
the direct or indirect damage caused by the loss of trading profit, the end of
business, the loss of commercial information or any other financial loss) resultant
of this product use or impossibility of use.
This program is supplied and conceded under license «AS IS», without warranty of
any sort, express or tacit, including, without limitation, implicit warranty of
market value and adaptability to special end. ILEX or any other third party
involved in the creation, the production or the delivery of the program, assume no
responsibility in any circumstance, of any direct or indirect damage including
damage for loss of profit, cessation of commercial activities or other, undergone
by the program user, even in the case ILEX would have been informed of such damage.
TO CONTINUE PRESS <ENTER>:
Results or performances of this program are totally assumed by the user. ILEX can
revoke this license at all times by informing the program user. The user can end
the software license by destroying or deleting all copy of the program.
This limited warranty will be interpreted under French law and in agreement with
the French law.
PROPERTY:
«SIGN&GO» and «MEIBO» and «INTRANEX» and «TRIPPER» are registered trademarks and
are protected by french law on trademark and intellectual property. The use of the
product name is strictly forbidden without ILEX specific written prior permission.
The program including its code, its documentation, its look, its structure and its
organisation, is a sole product of ILEX SYSTÈMES INFORMATIQUES, which permanently
keeps the property rights of the program or of its copies, changes or merged parts.
NB: for further information, please refer to the software license agreement in your
possession.
DO YOU ACCEPT THE TERMS OF THIS LICENSE AGREEMENT (Y/N): y
To accept the terms of the license, type “y” or “Y” then press Enter.
3.7 Product activation key

This screen enables the product activation key to be entered. The key will have been provided with the
product (it is often in a file named key.txt).

Sign&go
Browse to the file and select it by clicking the … button, the key value should then appear in the key
entry field. If the key has been sent as an attachment to an e-mail, the key value (a series of
characters after key= without the CR at the end of the line) can be copied and pasted into this field.
Click Next to continue.
3.7.2 Console mode

===============================================================================
Enter Activation Key
--------------------
Enter key filename:
Enter the absolute filename of the file containing the product key then press Enter.
If the file is located and it contains a valid key, the installer will move to the next step. Alternatively the
installer will remain at this step until a file with a valid key is located.
3.8 Choice of components

In this part of the installation the components to be installed can be chosen.
On Windows platforms, the security server can be installed with a pre-configured OpenLDAP v2
directory. This directory contains the Sign&go configuration data. To select this installation, choose
Complete Install from the menu.
Note: The Complete Install option enables the installation of a fully operational Sign&go
security server.
The Standard Install option enables the installation of the Sign&go security server and the
administration server. In this case the Sign&go configuration directory must be created in a LDAP
server (OpenLDAP, Active Directory or IPlanet/SunONE) at the end of the installation and connected

Sign&go
to the Sign&go security server for it to become operational. Refer to Initialising the configuration
directory page 39.
The security server can be installed on its own (without the administration) by choosing the Minimum
Install option. This option can be useful when installing several security servers; there is no need to
install the administration interface on all of the security servers.
The last option Custom Install enables the choice of which components to install.
The available components are:
 Sign&go security server,
 Administration server. This is an Apache Tomcat 5 application server with the following
applications:
 the Sign&go administration interface,
 the authentication pages,
 the self-registering,
 the Sign&go audit application,
 OpenLDAP (only on Windows).
Once the desired option has been selected, click Next.

If the Custom Install has been chosen, the following component selection screen appears:

Sign&go
3.8.2 Console mode

===============================================================================
Choose Product Features
-----------------------
Please choose the feature set to be installed by this installer.
->1- Standard install

2- Minimum install
3- Customise...
ENTER THE NUMBER FOR THE FEATURE SET, OR PRESS <ENTER> TO ACCEPT THE DEFAULT
:
Type the number of the desired option and press Enter. Pressing Enter without typing an option
number will result in the default installation type being chosen.
If the Custom Install has been chosen, the following component selection screen appears:
===============================================================================
Choose Product Components
-------------------------
Please choose the Components to be installed by this installer.
1- Security Server
2- Administration Server

Sign&go
ENTER A COMMA-SEPARATED LIST OF NUMBERS REPRESENTING THE COMPONENTS

TO BE INSTALLED:
3.9 Choice of directory

This screen lets you select the installation directory for the Sign&go components.
Choose the installation directory for the security server. Click Next to continue. The default installation
folder on Windows is C:\Program Files\Sign and go 5.0\.
Note: If the Complete Install option on the Windows platform was chosen, the OpenLDAP
directory will be installed into the openldap sub-folder of the installation’s root folder.
3.9.2 Console mode
===============================================================================
Choose Install Folder
---------------------
Where would you like to install?
Default Install Folder: /root/Sign_and_go
ENTER AN ABSOLUTE PATH, OR PRESS <ENTER> TO ACCEPT THE DEFAULT

:
Type the absolute pathname of the installation directory or keep the default. Press Enter.

Sign&go
3.10 Choice of shortcuts

This screen only appears on the Windows platform.
It allows you to specify the directory for the program’s shortcuts.
Select the location for the Sign&go shortcuts, and then click Next.
3.11 LDAP Parameters

If the included OpenLDAP directory is selected for installation (only on Windows platforms), this
screen presents the various parameters which must be configured in order that Sign&go can connect
to it and access its configuration data.
The various parameters are as follows:
 Hostname or IP address of the machine containing the Sign&go configuration directory,
 TCP access port of the directory (the Port number for directory servers is normally 3899),
 the Sign&go base DN (the root of the tree where the product’s configuration is stored),
 the user DN authorised to connect to the Sign&go base DN (this user can be situated in a tree
external to that of Sign&go),
 the authorised user’s password.

Sign&go
Note: If the Complete Install option was chosen or the LDAP component chosen under Custom
Install, the directory is automatically configured with the default parameters required for
communicating with the security server.
3.11.2 Console mode

===============================================================================
LDAP Directory Parameters
-------------------------
Please locate the LDAP Directory for Sign&go data recording.
Hostname or IP address(127.0.0.1):
TCP Port(3899):
DN Base(ou=signandgo,dc=ilex-si,dc=com):
DN User(cn=admin,ou=people,dc=ilex-si,dc=com):
User Password(admin):
The default value for each parameter is presented in brackets. To accept the default value simply press
‘Enter’, otherwise type the desired value followed by ‘Enter’.
3.12 Servers parameters

The following two screens enable configuration of Sign&go’s security server and administration server.

Sign&go
3.12.1 Administration server

The administration server consists of an Apache Tomcat 5 Servlet/JSP container which contains the
authentication applications, secondary accreditations management and the product’s administration.
This screen lets you define a login/password pair to be used for protecting access to the
administration Web application.
nd
The 2 screen requests a hostname or I/P address which will be used for dynamic generation of an
SSL server certificate in order to encrypt data exchanged with the administration application.
3.12.1.1 In graphical mode
3.12.1.2 In console mode

===============================================================================

Sign&go
Sign&go Administration Server Parameters

----------------------------------------
The following information is used to protect the Sign&go web application:

- login: the login to use;
- password: the associated password;
Login (DEFAULT: admin):

Password (DEFAULT: admin):
===============================================================================
Sign&go Administration Server Parameters
----------------------------------------
The following information is used to generate a SSL server certificate to protect

the Sign&go administration server.
The parameter is the hostname of the server which hosts the administration server.
Hostname or IP address (DEFAULT: ):
3.12.2 Security server

Enter the unique identifier of the security server. If the architecture comprises only one security server,
the default identifier can be kept. On the other hand, if the architecture comprises several security
servers, it is imperative that each server has its own unique identifier.
Note: The unique identifier is used during the operation of multi-domain SSO. For more
information, see the Sign&go architecture documentation.

Sign&go
3.12.2.1 Graphical mode
3.12.2.2 Console mode

===============================================================================
Security Server Parameters
--------------------------
Please configure Sign&go security server.

Server unique identifier must be unique for each security server. Please read the
security server documentation for more information.
Server unique identifier (Default: sngserver01):
3.13 Pre-installation summary

Before commencing installation of the selected components, the installer presents a summary of what
will be installed:

Sign&go
To start the installation, click Install.
3.13.2 Console mode

===============================================================================
Pre-Installation Summary
------------------------
Please Review the Following Before Continuing:
Product Name:
ILEX Sign&go - Servers
Install Folder:
/root/Sign_and_go
Link Folder:
/tmp/install.dir.5974/Do_Not_Install
Disk Space Information (for Installation Target):

Required: 96 395 895 bytes
Available: 5 849 374 720 bytes
To start the installation, press Enter.

Sign&go
3.14 Installation
A progress bar shows how the installation is progressing.
3.14.2 Console mode

===============================================================================
Installing...
------------------------
[==================|==================|==================|==================]
[--------
3.15 Regeneration of keys

Sign&go uses keys to encrypt its data, notably the session token.
These keys are configured by default during installation of the security server; it is highly
recommended that new keys be generated so as to not use the default ones.
The procedure for regenerating the keys is simple. Finish the installation then access the
administration interface with the URL: http://localhost:8080/signandgo/ or launch the Administration
Console shortcut.
The login ID and password are those entered during configuration of the security server, see page 20,
 in the left hand part of the interface under Configuration, click on General configuration,
 in the Management of session tokens on the right side of the interface, click on Change keys,
 further down in the Management of secondary credentials, click on Change SSO key,
 save the changes by clicking on the Save icon at the bottom of the page,
Sign&go
 The following screen is a reminder to generate the new keys
3.15.2 Console mode

===============================================================================
Important
---------
After Sign&go installation, please regenerate Sign&go token keys in the

Configuration section of the Sign&go administration.

Sign&go
3.16 Installation complete

3.16.2 Console mode

===============================================================================
Installation Complete
---------------------
ILEX Sign&go - Servers has been successfully installed to:
/root/Sign_and_go
PRESS <ENTER> TO EXIT THE INSTALLER:
4 POST INSTALLATION STEPS

4.1 Starting the servers
4.1.1 Windows platforms
On Windows platforms, if they are not already started at the end of the installation, start the Sign&go
system services:
 ILEX Sign&go v5.0 Administration Server,
 ILEX Sign&go v5.0 Security Server.
The services are started from Services within the Administrative Tools applet in the Control Panel.
To access the Sign&go administration, use the URL http://localhost:8080/signandgo/ or by launching
the Administration Console shortcut.

Sign&go
4.1.1.1 Complete Install on Windows

The Complete Install of the Sign&go security server on Windows installs and starts the following
supplementary system service:
 X Sign&go v5.0 OpenLDAP 2.0.27 Mod 1f.
4.1.1.2 JapserException error

In the case of an installation of the security server on a machine without a JVM (Java Virtual Machine)
loaded, the server will not automatically run on the Windows platform.
The Sign&go applications need the file tools.jar provided with the Java SDK platform in order to
compile the JSP pages. However, the link to the tools.jar file provided with the JVM no longer works,
therefore the following modifications to the file AdministrationServer.lax need to be carried out:
 parameter lax.class.path, delete ./jre/lib/tools.jar.
 parameter lax.nl.current.vm, should point to the java.exe of the SDK as opposed to the JRE.
4.1.2 Unix, Linux, Solaris platforms

Start-up of the administration server is carried out as follows:
cedric@VM-DEB-31-r3:~$ /home/cedric/sng32/AdministrationServer start&
In the same way, to start the security server, enter the following:
cedric@VM-DEB-31-r3:~$ /home/cedric/sng32/SecurityServer start&
To access the Sign&go administration, use the URL http://localhost:8080/signandgo/.
4.2 Sign&go Web administration application

The Sign&go administration is a Web application written in JSP. To function, it relies on a Java servlet
compatible Web server. The Sign&go installation provides the Apache Tomcat 5 Servlet/JSP container
for this purpose
Tomcat is a Java compatible Web server (it contains a Java servlet engine capable of executing JSP
pages). It comprises two distinct functionalities which we can activate or deactivate separately:
 the Web server,
 the Java servlet engine (for the JSP pages),
The default installation of Sign&go starts both of the Tomcat functionalities (Web server and
Application server).
For performance and security reasons it is recommended that the Web server functionality is disabled
and that Tomcat (as an application server) be connected to a dedicated Web server. The following
chapters describe how to disable the Tomcat Web functionality and install the Java servlet engine on
the various Web servers available.
4.2.1 Disabling Tomcat’s Web server functionality

The contents of this paragraph are common to all of the Web servers that are described in the
following pages.
Sign&go
Ensure that the administration server is stopped.

Edit the file ‘tomcat/conf/server.xml’ and find the following block of text:


<Connector port="8080"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />
Comment out the whole block as follows:



4.3 Integrating the administration server with IIS

(Windows)
Integration with IIS essentially consists of implementing the JK connector, which enables IIS to
delegate the JSP pages to Tomcat
Note: The directories mentioned in this chapter are relative to the Sign&go installation
directory. By default, the installation directory on Windows is C:\Program Files\Sign and go 5.0.
For example the directory tomcat/webapps corresponds to C:\Program Files\Sign and go
5.0\tomcat\webapps.
4.3.1 Deactivating Tomcat’s Web server functionality

See the chapter “Disabling Tomcat’s Web server functionality
on page 27.
4.3.2 Installing the JK connector

 Run the file tomcat/connectors/win32/1.2.8/isapi_redirect-1.2.8.exe in order to install the ISAPI
filter for Tomcat.
 Replace the file uriworkermap.properties which can be found in the conf sub-directory of the
connector’s installation directory (C:\Program Files\Apache Software Foundation\Jakarta Isapi
Redirector by default) by the one provided with Sign&go in tomcat/conf under the Sign&go
installation directory.
 Also copy the file tomcat/conf/workers.properties to the same directory and run regedit (menu
start/run/regedit) in order to modify the registry key worker_file which is located in
HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi
Redirector\1.0. Enter the absolute filename of the file that has just been copied (C:\Program
Files\Apache Software Foundation\Jakarta Isapi Redirector\conf\workers.properties).
Note 1: The logging level of the filter can be changed by editing the key
HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi
Redirector\1.0\log_level in the Windows registry. The available values for the key are: FATAL,
Sign&go
ERROR, WARNING, INFORMATION and DEBUG. The default location of the log files is in the
log sub-directory of the connector’s installation directory (C:\Program Files\Apache Software
Foundation\Jakarta Isapi Redirector\log).
Note 2: The files used by the ISAPI filter are workers.properties and uriworkermap.properties in
the conf sub-directory of the connector’s installation directory. These configuration files
contain comments and can be modified in order to better respond to specific requirements.
4.3.3 Creating the virtual directories for Sign&go static files

The Tomcat Application server only handles the JSP files. In order to make static files accessible, it is
necessary to create a virtual directory for each application within IIS.
Note: Tomcat can serve all of the files as opposed to just the JSP file. To do this the file
workers.properties in the conf sub-directory of the connector’s installation directory must be
modified to uncomment the corresponding lines (see the comments within the file). In this case
it is not necessary to create virtual directories within IIS.
1. Start the IIS administration console.

2. Using the mouse, right-click on Console Root/Internet Information
Server/[machine_name]/Default Web Site and select New/Virtual Directory.
3. Type signandgo.
4. Click Next.
5. Select the root location of the Sign&go Web application (C:\Program Files\Sign and go
5.0\tomcat\webapps\signandgo).
6. Click Next.
7. Click Finish.
8. Right mouse click on Console Root/Internet Information Server/[machine_name]/Default Web
Site and select New/Virtual Directory.
9. Type “logs”.
10. Click Next.
11. Select the root location of the logs Web application (C:\Program Files\Sign and go
5.0\tomcat\webapps\logs).
12. Click Next.
13. Click Finish.
14. Right mouse click on Console Root/Internet Information Server/[machine_name]/Default Web
Site and select New/Virtual Directory.
15. Type ’auth’.
16. Click Next.
17. Select the root location of the authentication Web application (C:\Program Files\Sign and go
5.0\tomcat\webapps\auth).
18. Click Next.
19. Click Finish.
20. Right mouse click on Console Root/Internet Information Server/[machine]/Default Web Site
and select New/Virtual Directory.
21. Type “selfregistering”.

Sign&go
22. Click Next.

23. Select the root location of the self-registering Web application (C:\Program Files\Sign and go
5.0\tomcat\webapps\selfregistering).
24. Click Next.
25. Click Finish.
Note: Ensure the anonymous connections are activated for the configured directories.
For each virtual directory created previously, (in Console Root/Internet Information
Server/[machine_name]/Default Web Site), right mouse click and select ‘properties’. On the
Directory Security tab, click on the ‘Edit’ button. Ensure that the Enable anonymous access
box is checked and that nothing is checked in the Authenticated access.
4.3.4 Restarting
Restart the Sign&go Administration server as well as the World Wide Web Publication service.
4.3.5 Verifying the installation

After restarting, enter the URL http://localhost/signandgo/ to access the portal (if necessary, specify
the IIS server port if it is anything other than 80). If the Sign&go administration is not presented, verify
that:
 the ISAPI filter is correctly installed (in the IIS administration console, right mouse click on
Console Root/Internet Information Server/[machine_name]/Default Web Site and verify that a
green arrow is displayed next to the line “jakarta”),
 the Sign&go administration server is started (if the administration server is installed as a system
service, verify the state of the service),
 there is no conflict between the Web server integrated with the portal and IIS (in other words that
they are not both using the same TCP port),
 the virtual directories in IIS are pointing to the correct locations,
 check the various logs in the Windows event logger,
 check the connector’s logs if necessary, change the connector’s logging level (see the note on
page 28).
Note: For more information, refer to the Apache JK connector documentation:

http://jakarta.apache.org/tomcat/connectors-doc/
4.4 Integrating the administration server with Apache 1.3

(Windows)
5.0\tomcat\webapps.


Sign&go
on page 27.
4.4.2 Adding the filter file to Apache

The procedure differs slightly depending upon whether the Apache server has integrated SSL support
or not.
4.4.2.1 Apache with SSL support (mod_ssl)

 Copy the file tomcat/connectors/win32/1.2.8/mod_jk-1.2.8-apache-1.3.33-eapi.so into the
Apache modules sub-directory (C:\Program Files\Apache Group\Apache).
 Rename it to mod_jk.s.
4.4.2.2 Apache without SSL support:

 Copy the file tomcat/connectors/win32/1.2.6/ mod_jk_1.2.6_1.3.31.dll into the Apache
modules sub-directory (C:\Program Files\Apache Group\Apache).
 Rename it to mod_jk.so.
4.4.3 Configuring the Apache filter

Edit the file httpd.conf in the conf sub-directory of the Apache installation in order to add the following
lines:
# Configuration Sign&go
#
Include "C:\Program Files\Sign and go 5.0\tomcat\conf\mod_jk.conf"
Note: The file mod_jk.conf contains comments which can be useful to read.
4.4.4 Restarting
Restart the Sign&go Administration server and Apache.

After restarting, access the portal via the URL http://localhost/signandgo/ (if necessary, specify the
Apache server port if it is anything other than 80). If the Sign&go administration is not presented, verify
that:
 there is no conflict between the Web server integrated with the portal and Apache (in other words
that they are not both using the same TCP port,
 check the various logs located in the logs sub-directory of the Apache installation, in particular
the file jk.log. The connecter’s logging level can be changed by modifying the value of the
JkLogLevel line in the file tomcat/conf/mod_jk.conf. The available levels are: FATAL, ERROR,
WARNING, INFORMATION and DEBUG,
 check the various logs in the Windows event logger.

Sign&go
4.5 Integrating the administration server with Netscape

SuiteSpot (Windows)
5.0\tomcat\webapps.

on page 27.
4.5.2 Updating the Netscape-Tomcat configuration file

 Edit the tomcat/conf/obj.conf template file in order to match the existing configuration if
necessary.
 Ensure that the pathnames in the configuration file only contain slashes (“/”).
 If necessary replace any back-slashes (“\”) with forward-slashes (“/”).
4.5.3 Merging the configuration template file with that of

Netscape SuiteSpot
Edit the Netscape SuiteSpot Web server’s obj.conf file. This file is located in the https-[web server
DNS name]/config sub-directory of the Netscape SuiteSpot installation. Merge it with the previously
modified template file.
An example of a merged configuration file is given here:
Init fn="load-modules" funcs="jk_init,jk_service" shlib="C:/Program

Files/Sign and go 3.1/tomcat/connectors/win32/1.2.8/nsapi_redirect-
1.2.8.dll"
Init fn="jk_init" worker_file="C:/Program Files/Sign and go
3.1/tomcat/conf/workers.properties" log_level="information"
log_file="C:/Program Files/Sign and go 3.1/logs/netscape_redirect.log"
Init fn=flex-init access="C:/Netscape/SuiteSpot/https-
ixtestnt44/logs/access" format.access="%Ses->client.ip% - %Req->vars.auth-
user% [%SYSDATE%] \"%Req->reqpb.clf-request%\" %Req->srvhdrs.clf-status%
%Req->srvhdrs.content-length%"
Init fn=load-types mime-types=mime.types
<Object name=default>
NameTrans fn="assign-name" from="/signandgo/*.jsp" name="servlet"
NameTrans fn="assign-name" from="/cps/*.jsp" name="servlet"
NameTrans fn="assign-name" from="/selfregistering/*.jsp" name="servlet"
NameTrans fn=pfx2dir from=/ns-icons dir="C:/Netscape/SuiteSpot/ns-icons"
NameTrans fn=pfx2dir from=/mc-icons dir="C:/Netscape/SuiteSpot/ns-icons"
NameTrans fn=pfx2dir from="/help"
dir="C:/Netscape/SuiteSpot/manual/https/ug"
NameTrans fn=pfx2dir from="/signandgo" dir="C:/Program Files/Sign and go
3.1/tomcat/webapps/signandgo"
NameTrans fn=pfx2dir from="/logs" dir="C:/Program Files/Sign and go
3.1/tomcat/webapps/logs"
NameTrans fn=pfx2dir from="/selfregistering" dir="C:/Program Files/Sign and
go 3.1/tomcat/webapps/selfregistering"
NameTrans fn=pfx2dir from="/auth" dir="C:/Program Files/Sign and go
3.1/tomcat/webapps/auth"
NameTrans fn=document-root root="C:/Netscape/SuiteSpot/docs"
PathCheck fn="deny-existence" path="*/WEB-INF/*"

Sign&go
PathCheck fn=nt-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.html,home.html"
ObjectType fn=type-by-extension
ObjectType fn=force-type type=text/plain
Service method=(GET|HEAD) type=magnus-internal/imagemap fn=imagemap
Service method=(GET|HEAD) type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
AddLog fn=flex-log name="access"
</Object>
<Object name=cgi>
ObjectType fn=force-type type=magnus-internal/cgi
Service fn=send-cgi
</Object>
<Object name=servlet>
ObjectType fn=force-type type=text/html
Service fn="jk_service" worker="ajp13" path="/*"
</Object>
4.5.4 Restarting
Restart the Sign&go Administration server and Netscape Web server.

Netscape Web server port if it is anything other than 80). If the Sign&go administration is not
presented, verify that:
 the Netscape Web server is started. If the server does not start, verify the link to the nsapi filter in
the obj.conf file,
that they are not both using the same TCP port),
 check the various log files located in the https-[web-server DNS name]/logs sub-directory of the
Netscape installation,
 check the various log files in the C:/Program Files/Sign and go 5.0/logs directory,
4.6 Integrating the administration server with IPlanet 6.x

(Windows)
5.0\tomcat\webapps.

Sign&go

on page 27.
4.6.2 Configuring iPlanet

iPlanet 6.X already contains a servlet engine. There are therefore two solutions available:
 stop the servlet engine in the iPlanet Web server,
 create a new Web server in iPlanet and disable the servlet engine in it.
4.6.2.1 Update the IPLANET-Tomcat configuration file

 Edit the tomcat/conf/obj.conf template file in order to match the existing configuration if
necessary.
 Ensure that the pathnames in the configuration file only contain slashes (“/”). If necessary replace
any back-slashes (“\”) with forward-slashes (“/”).
4.6.2.2 Create a new Web server in iPlanet

If the creation of a new Web server is not required, go directly to the next section.
 Start the iPlanet Administration Server.
 On the SERVERS tab, select the ADD SERVER page.
 Modify the SERVER PORT so as not to conflict with the default Web server and enter a new
name for the SERVER IDENTIFIER. Save the changes by clicking OK.
4.6.2.3 Merge the configuration template file with that of the iPlanet Web
server’s configuration file
 Edit the iPlanet Web server’s obj.conf file.
 Note: This file is located in the https-[Web server DNS name (or the name defined by
SERVER IDENTIFIER)]/config sub-directory of the IPLANET installation.
 Merge it with the previously modified template file but without the Init fn= lines.
The Init fn= lines must be inserted into the iPlanet Web server’s magnus.conf configuration file which
can be found in he same directory.
An example of a merged configuration file is given here:
********* FICHIER MAGNUS.CONF *********

#ServerRoot C:/iPlanet/Servers/https-SIGNANDGO
ServerID https-SIGNANDGO
ServerName PMAR
ExtraPath C:/iPlanet/Servers/bin/https/bin;${NSES_JRE_RUNTIME_LIBPATH}
ErrorLog C:/iPlanet/Servers/https-SIGNANDGO/logs/errors
MtaHost name-of-mail-server
DNS off
Security off
ClientLanguage en
AdminLanguage en
DefaultLanguage en
RqThrottle 128

Sign&go
Init fn=flex-init access="$accesslog" format.access="%Ses->client.ip% -

%Req->vars.auth-user% [%SYSDATE%] \"%Req->reqpb.clf-request%\" %Req-
>srvhdrs.clf-status% %Req->srvhdrs.content-length%"
Init fn=load-types mime-types=mime.types
Init fn="load-modules"
shlib="C:/iPlanet/Servers/bin/https/bin/NSServletPlugin.dll"
funcs="NSServletEarlyInit,NSServletLateInit,NSServletNameTrans,NSServletSer
vice" shlib_flags="(global|now)"
Init fn="NSServletEarlyInit" EarlyInit=yes
Init fn="NSServletLateInit" LateInit=yes
Init fn="load-modules" funcs="jk_init,jk_service" shlib="C:/Program
Files/Sign and go 3.1/tomcat/connectors/win32/1.2.8/nsapi_redirect-
1.2.8.dll"
Init fn="jk_init" worker_file="C:/Program Files/Sign and go
3.1/tomcat/conf/workers.properties" log_level="debug" log_file="C:/Program
Files/Sign and go 3.1/logs/netscape_redirect.log"
********* FICHIER OBJ.CONF *********

# Use only forward slashes in pathnames--backslashes can cause
# problems. See the documentation for more information.
<Object name=default>
#########################################################
# configuration for the /signandgo context starts.
#########################################################
NameTrans fn="assign-name" from="/signandgo/*.jsp" name="servlet"

NameTrans fn="assign-name" from="/logs/*.jsp" name="servlet"
NameTrans fn="assign-name" from="/auth/*.jsp" name="servlet"
NameTrans fn="assign-name" from="/selfregistering/*.jsp" name="servlet"
NameTrans fn=pfx2dir from="/signandgo" dir="C:/Program Files/Sign and go

3.1/tomcat/webapps/signandgo"
NameTrans fn=pfx2dir from="/logs" dir="C:/Program Files/Sign and go
3.1/tomcat/webapps/logs"
NameTrans fn=pfx2dir from="/auth" dir="C:/Program Files/Sign and go
3.1/tomcat/webapps/auth"
NameTrans fn=pfx2dir from="/selfregistering" dir="C:/Program Files/Sign and
go 3.1/tomcat/webapps/selfregistering"
#######################################################
# configuration for the /signandgo context ends.
#######################################################
#######################################################
# Protecting the web inf directory.
#######################################################
PathCheck fn="deny-existence" path="*/WEB-INF/*"
NameTrans fn="NSServletNameTrans" name="servlet"

NameTrans fn="pfx2dir" from="/servlet"
dir="C:/iPlanet/Servers/docs/servlet" name="ServletByExt"
NameTrans fn=pfx2dir from=/mc-icons dir="C:/iPlanet/Servers/ns-icons"
name="es-internal"
NameTrans fn="pfx2dir" from="/manual" dir="C:/iPlanet/Servers/manual/https"
name="es-internal"
NameTrans fn=document-root root="$docroot"
PathCheck fn=nt-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.html,home.html"
ObjectType fn=type-by-extension

Sign&go
ObjectType fn=force-type type=text/plain

Service type="magnus-internal/jsp" fn="NSServletService"
Service method=(GET|HEAD) type=magnus-internal/imagemap fn=imagemap
Service method=(GET|HEAD) type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
AddLog fn=flex-log name="access"
</Object>
<Object name=cgi>
ObjectType fn=force-type type=magnus-internal/cgi
Service fn=send-cgi
</Object>
<Object name="servlet">
Service fn="NSServletService"
</Object>
<Object name="jsp092">
ObjectType fn="type-by-extension"
ObjectType fn="change-type" type="magnus-internal/jsp092" if-type="magnus-
internal/jsp"
Service fn="NSServletService" type="magnus-internal/jsp092"
</Object>
<Object name="ServletByExt">
ObjectType fn=force-type type=magnus-internal/servlet
Service type="magnus-internal/servlet" fn="NSServletService"
</Object>
<Object name="es-internal">
PathCheck fn="check-acl" acl="es-internal"
</Object>
#######################################################
# New object to execute your servlet requests.
#######################################################
<Object name=servlet>
Service fn="jk_service" worker="ajp13" path="/*"
</Object>
4.6.2.4 Deactivate IPLANET’s servlet engine

 Stop the servlet engine in the iPlanet Web server
In the previously merged IPLANET obj.conf file, locate the following block of definitions:
<Object name="servlet">
Service fn="NSServletService"
</Object>
Comment out the whole block:
#<Object name="servlet">
#ObjectType fn=force-type type=text/html
#Service fn="NSServletService"
#</Object>

Sign&go
4.6.3 Restarting
Restart the Sign&go Administration server and the IPLANET Web server.

Netscape Web server port if it is anything other than 80). If the Sign&go administration is not
presented, verify that:
 the iPlanet Web server is started. If the server does not start, verify the link to the nsapi filter in the
obj.conf file,
 there is no conflict between the Web server integrated with the portal and iPlanet (in other words
 check the various log files located in the https-[web-server DNS name]/logs sub-directory of the
iPlanet installation,
 check the various log files in the C:/Program Files\Sign and go 5.0\logs directory,
4.7 Integrating the administration server with Apache 1.3

(UNIX)
5.0\tomcat\webapps.

on page 27.
4.7.2 Adding the filter file to Apache

Copy the file tomcat/connectors/linux/mod_jk.so-eapi to the libexec sub-directory of the Apache
installation and rename it to mod_jk.so.
Configuring the Apache filter

Edit the file httpd.conf in the conf sub-directory of the Apache installation in order to add the
following lines:
# Configuration Sign&go
#
Include "/opt/sign_and_go_3.1/conf/mod_jk.conf"
Note: The file mod_jk.conf contains comments which can be useful to read.

Sign&go
4.7.3 Restarting
Restart the Sign&go Administration server and Apache.

Apache server port if it is anything other than 80).
If the Sign&go administration is not presented, verify that:
 check the various logs located in the logs sub-directory of the Apache installation, in particular the
file jk.log. The connecter’s logging level can be changed by modifying the value of the
JkLogLevel line in the file tomcat/conf/mod_jk.conf. The available levels are: FATAL, ERROR,
WARNING, INFORMATION and DEBUG,

Sign&go
5 INITIALISING THE CONFIGURATION DIRECTORY

In order to better integrate Sign&go in some environments, the Sign&go configuration data can be
installed in an existing directory. The following chapters describe these installations.
5.1 Integration with OpenLDAP

Note: If a Complete Install of the Sign&go security server on Windows was carried out,
OpenLDAP is already installed and configured There is therefore no need to refer to this
chapter.
Sign&go is compatible with OpenLDAP versions 2.0.x and higher.
5.1.1 Windows platform

If an OpenLDAP is already installed, it only needs to be configured as described in paragraph
Configuring OpenLDAP page 57.
5.1.1.1 Installing OpenLDAP

The OpenLDAP server, pre-configured for Sign&go, can be installed by the Ilex install program. To do
this, launch the security server installation and select Custom Install followed by the openldap
option.
This installation pre-configures the directory so there is no need to proceed to the next section.
5.1.1.2 Configuring OpenLDAP

The following configuration guide presumes that OpenLDAP has been installed in the C:\openldap
and that the directory containing the data is C:\openldap\openldap-data.
The various configuration files on the Sign&go CD-ROM for carrying out this configuration are located
in the \annuaire\openldap\windows directory.
Follow the steps below:
1. add the following lines to the file C:\openldap\slapd.conf :
database ldbm
suffix "dc=ilex-si,dc=com"
rootdn uid=Manager,ou=people,dc=ilex-si,dc=com
rootpw marsupilami
directory "c:/openldap/openldap-data"
index default pres,eq
index uid,cn,sn,sngname
index objectClass eq
To adapt these lines to the company’s environment (a domain different from ilex-si.com, for example
entreprise.fr); modify the suffix and rootdn parameters to indicate the domain name as follows:
database ldbm
suffix "dc=entreprise,dc=fr"
rootdn uid=Manager,ou=people,dc=entreprise,dc=fr
rootpw marsupilami
directory "c:/openldap/openldap-data"
index default pres,eq

Sign&go
index uid,cn,sn,sngname
index objectClass eq
2. modify the file init.ldif in the \annuaire\openldap\windows directory on the CD-ROM and
enter a different domain name. The file contains the following lines:
dn: dc=ilex-si,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
dc: ilex-si
o: Ilex Corporation
description: La racine Ilex
# Organizational Role for Directory Manager

dn: uid=Manager,ou=people,dc=ilex-si,dc=com
objectClass: organizationalRole
cn: Manager
description: Directory Manager
To configure entreprise.fr (dc=entreprise,dc=fr) as the domain name, the two lines dn: and dc:
must be changed as follows:
dn: dc=entreprise,dc=fr
objectClass: top
objectClass: dcObject
objectClass: organization
dc: entreprise
o: Ilex Corporation
description: La racine Ilex
# Organizational Role for Directory Manager

dn: uid=Manager,ou=people,dc=entreprise,dc=fr
objectClass: organizationalRole
cn: Manager
description: Directory Manager
3. enter the following command in a Command Window (DOS) from within the C:\openldap
directory:
slapadd.exe -f slapd.conf -l d:\annuaire\openldap\windows\init.ldif
4. extend the directory’s schema by copying the file signandgo.schema from the CD-ROM into
the C:\openldap\schema\ sub-directory,
5. insert the following line into the file C:\openldap\slapd.conf :
include "c:/openldap/schema/signandgo.schema"
6. start the OpenLDAP server with the following command:
slapd.exe
7. modify the file data.ldif on the CD-ROM to replace every occurrence of dc=ilex-si,dc=com by
the chosen domain name and copy this file into C:\openldap,
8. run the following command in order to insert the Sign&go data into the OpenLDAP directory
(specifying the correct domain name):
Sign&go
ldapmodify -a -f c:\openldap\data.ldif -x -D
"uid=Manager,ou=people,dc=ilex-si,dc=com" -w marsupilami
9. Edit the file “CRL CPS Exploitation.ldif ” on the CD-ROM and replace all occurrences of
“dc=ilex-si,dc=com” with your required domain name and copy the file to “C:\openldap”.
10. Execute the following command in order to insert the Sign&go base data into the directory.
Specify your required domain name in the command line:
ldapmodify -a -f "c:\openldap\CRL CPS Exploitation.ldif" -x -D

"uid=Manager,ou=people,dc=ilex-si,dc=com" -w marsupilami
5.1.2 Linux platform

5.1.2.1 Installing OpenLDAP
A version of OpenLDAP was probably supplied with the Linux distribution. If it is version 2.0 or higher,
it can be installed at the same time as Linux. In this case go directly to step “Configuring OpenLDAP”.
If OpenLDAP is not installed, please use your distribution’s package manager to install the latest
OpenLDAP version
5.1.2.2 Configuring OpenLDAP

The configuration of OpenLDAP is carried out in the same way as on the Windows platform, only the
locations of the ‘slapd.conf” file and schemas are different: their location depends on the Linux
distribution that you are using.
Once the files have been located, please refer to the “Configuring OpenLDAP” section on page 39
5.1.3 Security server configuration

After configuring OpenLDAP, it is best to verify the security server configuration by following the steps
outlined below.
5.1.3.1 Configuring the Sign&go data-connector to point to the directory

 Edit the configuration file server/server.xml located in the Sign&go installation.
 Locate the <DataSource> element corresponding to the data-connector configuration.
 Edit the following lines in order to insert respectively, the directory connection URL, the user
identifier and password for connecting to the directory and the directory’s base DN where the
Sign&go data are stored:
<JNDIUrl>ldap://localhost:389</JNDIUrl>
<DN>cn=admin,ou=people,dc=ilex-si,dc=com</DN>
<DNPassword>admin</DNPassword>
<Base>ou=signandgo,dc=ilex-si,dc=com</Base>
Refer to the chapter explaining the security server’s configuration file for more information concerning
these modifications.
5.1.3.2 Starting the LDAP server

If the LDAP server is already running, stop and re-start it for it to take the new parameters into
account.
5.1.3.3 Starting the Security server

If the Security server is already running, stop and re-start it for it to take the new parameters into
account and connect to the directory.
Sign&go
5.1.3.4 Starting the Sign&go Administration server

If the Administration server is already running, stop and re-start it for it to take the new parameters into
5.1.3.5 Verifying the installation

If the connection is not made, verify that:
 the OpenLDAP server is correctly installed by connecting with a LDAP browser such as
LDAPBrowser,
 the OpenLDAP database has been created correctly (use a LDAP browser such as LDAPBrowser
to verify),
 the schema extension is effective (creation of a sngXXX object with the aid of a LDAP browser
such as LDAPBrowser),
 if OpenLDAP no longer runs, start it with the following command line in order to study the logs
messages:
slapd –d –1
The problem is often due to a syntax error in the slapd.conf file or the schema files.
 the modification carried out to the server/server.xml file, such as the connection URL, base DN
and the BIND identifier are correct.
5.2 Integration with Active Directory

The Sign&go data can be stored in Windows Active Directory. The various configuration files for
carrying out this installation can be found in the server/active directory/ sub-directory of the Sign&go
installation.
5.2.1 Modifying the Active Directory schema

Modification of the Active Directory schema can be carried out by executing the file server/active
directory/EnableSchemaExtension.reg located in the installation directory. The Windows registry
key to be modified is the following:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Schema Update Allowed"=dword:00000001
5.2.2 Extending the Active Directory schema

The next step consists of extending the Active Directory schema with the LDAP objects required for
Sign&go. A batch file is available on the CD-ROM for adding the schemas. This file can be found in
the ‘annuaire/Active Directory‘ directory.
The file is named ‘installschemaAD.cmd’ and it needs to be adapted to suit your installation
environment.
Therefore the following changes may need to be carried out:
 modify the schema’s root (it is defined as ‘dc=sng-ad-test,dc=fr’ in the batch file) to that used by
your company;
 modify the address of the Active Directory server (defined as ‘localhost’ in the batch file);
 if the current user does not have rights on the schema, specify one who does.
 Once the modifications have been carried out, simply run the batch file:
installschemaAD

Sign&go
5.2.3 Deactivating modification of the Active Directory

schema
Once modification of the schema has been completed, it is recommended that further schema
modifications be de-activated. This can be carried out by executing the file ‘annuaire/Active
Directory/DisableShemaExtension.reg’.
The file will modify the following Windows registry key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Schema Update Allowed"=dword:00000000
5.2.1 Importing the Sign&go data into the directory

The files containing the data to be imported are located on the Sign&go installation CD in the
‘annuaire/ldif’ directory.
To import the LDIF files, enter the following command in a Command Prompt window:
ldifde -i -s localhost -v -f data.ldif -c "dc=ilex-si,dc=com"

"dc=acme,dc=com"
The command line above, imports the file ‘data.ldif’, converting the dc=ilex-si,dc=com ‘’ DN’s to
‘dc=acme,dc=com’, on the local host (-s localhost parameter).
5.2.2 Configuring the Sign&go data connecter to point to the

directory
 Edit the configuration file /server/server.xml located in the Sign&go installation directory.
 Locate the <DataSource> element corresponding to the data connecter configuration.
<DN>uid=Manager,ou=People,dc=ilex-si,dc=com</DN>
<DNPassword>marsupilami</DNPassword>
5.2.3 Starting the Security server

5.2.4 Starting the Sign&go Administration server


such as LDAPBrowser ),
 the Sign&go sub-tree exists in the directory,
Sign&go
 the modifications carried out to the server/server.xml file, such as the connection URL, base DN
5.3 Integration with ADAM

The Sign&go data can be stored in a Microsoft ADAM (Active Directory Application Mode) directory.
The various configuration files required to carry out the installation can be found in the
‘annuaire/Active Directory/’ sub-directory of the Sign&go installation.
5.3.1 Extending the ADAM schema

In order to extend the ADAM schema, the directory’s GUID needs to be obtained. This is done by
running the ADAM ADSIedit utility and locating the CN attribute as shown in the screen capture below:
Once the GUID has been obtained, the batch file ‘installschemaAD.cmd’ must be modified for your
environment:
Replace the schema root (the value in the batch file is set to ‘dc=sng-ad-test,dc=fr’) with the GUID
value obtained previously;
Replace the ADAM’s server address (the value in the batch file is set to ‘localhost’);
If the current user does not have rights on the schema, then specify one who does.
 Once the modifications have been completed, simply launch the batch file as follows:
installschemaAD
5.3.2 Importing the Sign&go data into the directory

To import the LDIF files, enter the following command in a Command Prompt window:

Sign&go
ldifde -i -s localhost -v -f data.ldif -c "dc=ilex-si,dc=com"

"dc=acme,dc=com"
The command line above, imports the file ‘data.ldif’, converting the dc=ilex-si,dc=com ‘’ DN’s to
‘dc=acme,dc=com’, on the local host (‘-s localhost’ parameter).
5.3.3 Configuring the Sign&go data connector to point to the

directory
Edit the ‘/server/server.xml’ configuration file located in the Sign&go installation directory.
Locate the section ‘<DataSource>’ which corresponds to the data connector configuration.
Edit the following lines in order to insert the connection URL, identifier and password to be used for
connecting to the directory as well as the base DN where the Sign&go data is stored:
Refer to the detailing the Security Server configuration file for more information regarding these
parameters.
5.3.4 Starting the security server

If the security server is already running, stop and restart it in order for it to connect to the configuration
directory.
5.3.5 Start the Sign&go administration

If the administration server (Tomcat) is already running, stop and restart it in order for it to connect to
the configuration directory.

If problems exist, verify:
 Use an LDAP browser to verify that the schema has been correctly extended (creation of sngXXX
object),
 that the Sign&go sub-tree exists in the directory,
 verify the changes made to the ‘server/server.xml’ file, connection URL, base DN and bind
username/password
5.4 Integration with IPlanet Directory Server 4

The Sign&go data can be stored in a Netscape/IPlanet Directory Server 4 directory. The various
configuration files for implementing this installation are located in the server/IPlanet Directory Server
4/ sub-directory of the Sign&go installation.
5.4.1 Extending the IPlanet Directory Server schema

Copy the files slapd.user_at.conf and slapd.user_oc.conf into the directory’s
/netscape/Server4/slapd-<server_name>/config configuration directory. Restart the directory for
the schema extension to be taken into account.

Sign&go
5.4.2 Inserting the Sign&go data into the directory

Insert the data contained in the data.ldif file into the directory with the aid of the Netscape console
(right-click on the Database entry in the tree on the Configuration tab, then select Import). The file
data.ldif is located in the server/IPlanet Directory Server 4/ sub-directory of the Sign&go installation.
Note: The file data.ldif contains the base DN dc=ilex-si,dc=com for inserted objects. To insert
data into the directory, replace this base DN with that of the company’s (for example
dc=acme,dc=com).

directory


If the Administration server is already running, stop and re-start for it to take the new parameters into


Sign&go
5.5 Integration with IPlanet Directory Server 5

The Sign&go data can be stored in a Netscape/IPlanet Directory Server 5 directory. The various
configuration files for implementing this installation are located in the server/IPlanet Directory Server
5/ sub-directory of the Sign&go installation.
5.5.1 Extending the IPlanet Directory Server schema

Copy the file 99signandgo.ldif into the directory’s configuration directory. Restart the directory for the
schema extension to be taken into account.
5.5.2 Inserting the Sign&go data into the directory

Insert the data contained in the data.ldif file into the directory with the aid of the Netscape console
(right-click on the Database entry in the tree on the Configuration tab, then select Import.
Note: The file data.ldif contains the base DN dc=ilex-si,dc=com for inserted objects. To insert
data into the directory, replace this base DN with that of the company’s (for example
dc=acme,dc=com).

directory




Sign&go

Sign&go
6 CONFIGURING THE SIGN&GO SECURITY SERVER

This chapter presents the various files installed during the installation of Sign&go. It brings together all
the information regarding the configuration of the Sign&go security server and Sign&go Administration.
Note: The various information detailed in this chapter uses the Complete Install (with
OpenLDAP) of the security server on Windows in the C:\Program Files\Sign and go 5.0\ for its
examples. Nevertheless, the information is still valid for installations on Unix platforms.
6.1 Overview of the installation

Once the Sign&go security server is installed, several shortcuts are available on the Start menu:
These shortcuts correspond respectively to:

 launch the Administration Console in the machine’s default browser. The Sign&go Administration
is accessible from http://localhost:8080/signandgo/start.jsp. The identifier and password are the
ones that were configured in the ‘Sign&go Administration Server Parameters’ step of the
Installation process,
 display the Administration’s contextual help in the machine’s default browser. The help can also
be accessed directly from the hard-drive at C:\Program Files\Sign and go
5.0\webapps\signandgo\aide\help.html. The PDF files are not installed on the hard-drive, insert
the Sign&go CD-ROM to consult them,
 start the Sign&go Administration server in console mode.
Attention: On Windows platforms, the Administration server is also installed as a system

service with automatic start-up; in this case there is no need to start it here. The Administration
server can also be started with the C:\Program Files\Sign and go 5.0\AdministrationServer.exe
executable.
 start the OpenLDAP directory server containing the Sign&go data,
Attention: On Windows platforms, the OpenLDAP server is also installed as a system service
with automatic start-up; in this case there is no need to start it here. The OpenLDAP server can
also be started with the C:\Program Files\Sign and go 5.0\openldap\slapd.exe executable.
 start the Sign&go security server.
Attention: On Windows platforms, the security server is also installed as a system service with
automatic start-up; in this case there is no need to start it here. The security server can also be
started with the C:\Program Files\Sign and go 5.0\SecurityServer.exe executable.

Sign&go
The installation directory contains various sub-directories:
Sub-directories
bin Contains various internal Sign&go files.
classes Empty by default, contains Java classes for the various integration
developments related to the security server.
client APIs Contains the Sign&go token management APIs, the JavaDoc documentation
and examples.
doc Contains the development documentation related to the security server
jre Contains the Java Virtual Machine used by Sign&go.
lib Contains the various Java libraries used by Sign&go.
logsng Contains the database of authorisation and authentication logs used by the
logs Web application.
openldap Contains all the files concerning OpenLDAP such as the OpenLDAP Sign&go
configuration. This directory only exists if a Complete Install was carried out.
server Contains the security server configuration files in addition to the various files
necessary for integrating the Sign&go data with third-party LDAP directories.
server/logs Contains the security server logs:

 Authentication,
 Authorisation,
 Events,
 Statistics.
tomcat Directory where Apache Tomcat 5 is installed.
tomcat/conf Contains the various Tomcat configuration files.
tomcat/connectors Contains the various files enabling the Tomcat application server to be
connected to the most common Web servers for the Windows, Linux and
Solaris platforms.

Sign&go
Sub-directories
tomcat/logs Contains the various Tomcat Web server log files.
tomcat/webapps Root of the Tomcat Web applications. The various JSP files that constitute the
Sign&go Administration component (/signandgo), the various JSP files that
constitute the Sign&go logs application (/logs), the various JSP files that
constitute the self-registering (of users) application (/selfregistering) and the
various JSP files that constitute the users-authentication application (/auth).
tomcat/work Working directory created by Tomcat during start-up, it contains no user

exploitable data.
tracer This directory contains the Ilex logging console.
wars Directory containing the Sign&go applications in the form of .war files.
To install these Sign&go applications in a different application server, consult
the Installation of .war files annex on page 91.
6.2 Configuration of the Sign&go administration server

The administration server is executed with the aid of the Apache Tomcat application server –
Remember that the Sign&go Administration consists of the Tomcat application server and the various
Sign&go Web applications. Various documents concerning the configuration of Tomcat can be found
at http://jakarta.apache.org/tomcat/index.html. Nevertheless, certain basic operations are detailed
below:
Note: The Tomcat documentation can equally be consulted at the following URL:
http://localhost:8080/tomcat-docs/.
6.2.1 Modifying the Administration server’s listener port

By default the integrated Sign&go Administration server listens on port 8080. The port can be changed
in order to, for example, listen on the default HTTP protocol’s port (80). To do this, edit the Tomcat
configuration file tomcat/conf/server.xml in the Sign&go installation directory and locate the following
block of definitions:
<Connector className="org.apache.tomcat.service.PoolTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
<Parameter name="port" value="8080"/>
</Connector>
Change the value 8080 to the desired port number and restart the Sign&go Administration server.
The Web server functionality integrated with Tomcat can be deactivated by simply commenting out the
block of definitions in the following manner (see also Integration with Tomcat with IIS (Windows)):

6.2.2 Managing access profiles

Various profiles are available for accessing the Sign&go Administration interface:

Sign&go
 admin. The default profile, it enables access to all of the administration interface’s pages and can
perform READ, MODIFY and DELETE operations. The default password is admin,
 operator. Profile for managing the security policies, rights, rules and behaviours. It can only
READ, MODIFY and DELETE in the Authorisations section. Other sections are READ only. The
default password is operator,
 helpdesk. Profile for carrying out READ operations throughout the various sections. The default
password is helpdesk.
6.2.3 Modifying the password of a profile

The Sign&go security server relies on the Java Servlet specifications for managing access rights, it is
therefore left to the Java application engine to manage the user accounts. By default, Tomcat is
provided with account management in the form of an XML file. To change the password of any of the
default accounts mentioned above or to add new accounts, edit the file tomcat\conf\tomcat-
users.xml. This file takes the form:
<tomcat-users>
<role rolename="helpdesk"/>
<role rolename="manager"/>
<role rolename="operator"/>
<role rolename="admin"/>
<user username="helpdesk" password="helpdesk" roles="helpdesk"/>
<user username="operator" password="operator" roles="operator"/>
<user username="admin" password="admin" roles="admin,manager"/>
</tomcat-users>
The file can be modified at will, bearing in mind that only user’s having the admin or operator role can
administer Sign&go.
6.2.4 Validating the profiles on LDAP

The Sign&go administration server relies on the Java-Servlet specification for managing access rights;
it is therefore left to the Java application engine to manage the user account. The administration
server (Tomcat) is delivered with a file-based account management (see below) by default.
Nevertheless, it is equally possible to authenticate the Sign&go Administration’s users on an LDAP
directory.
The following example describes how to use OpenLDAP supplied with Sign&go to authenticate the
user. The Tomcat parameters need to be modified so as to use a specific directory rather than the
tomcat\conf\tomcat-users.xml file supplied with Tomcat.
Edit the file tomcat/conf/server.xml and locate the following block of definitions:
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
debug="0" resourceName="UserDatabase"/>
In order to comment them out:

Add the following definitions just after the newly commented out block:

Sign&go
<Realm className="org.apache.catalina.realm.JNDIRealm"
debug="0"
connectionName="cn=admin,ou=people,dc=ilex-si,dc=com"
connectionPassword="admin"
connectionURL="ldap://localhost:3899"
userPattern="cn={0},ou=people,dc=ilex-si,dc=com"
userRoleName="sn"
/>
Save the file and restart the Sign&go Administration server.

In this example, the default Sign&go service account (cn=admin,ou=people,dc=ilex-si,dc=com) is used
to locate the user and their corresponding role is their sn.
Note: The service account is the one that enables connecting to the directory with READ and
WRITE privileges.
To use the company’s own directory, refer to the JNDI Realm documentation. This documentation is
available on:
 the Tomcat site: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/printer/realm-howto.html
 the local machine: http://localhost:8080/tomcat-docs/realm-howto.html#JNDIRealm.
6.3 Configuration of the security server

The various security server configuration parameters are stored in several configuration files in the
‘server’ directory:
 the ‘server.xml’ file contains the location of the LDAP directory, the product activation key and
several other parameters;
 The ‘genway.xml’ file contains definitions for the security server’s listening ports, the location of
the SSL certificates, etc;
 the ‘cache.xml’ file which allows configuration of the “Statefull” mode, used only when tokens are
stored on the security server.
Attention: Do not confuse the Tomcat server configuration file that is located in the
tomcat/conf sub-directory with that of the security server which is located in the server sub-
directory.
6.3.1 Changing the security server’s listener port

The security server listens on 4 TCP ports: 2 unencrypted (3100 and 4100 by default) and 2 SSL
protected ports (3102 and 4102 by default) with mutual authentication.
The security server can be configured to use different ports from the default ones.
To change the default ports, the ‘’ file must be modified. The ‘<Listens>’ section contains the various
parameters concerning the ports.
The ‘<Listens>’ section must resemble the following:

<Listens>

Sign&go
...
<Listen name="SynchronousNoSSL">
<param name="Address" value=""/>
<param name="Port" value="3100"/>
</Listen>
<Listen name="AsynchronousNoSSL">
</Listen>
<Listen name="SynchronousSSL">
<param name="ServerSocket" value="com.ilex.sock.PureTLSServerSocket" />
<param name="SSLFlag" value="true" />
<param name="SSLRootCertificate"
value="../resources/certificates/root.pem" />
<param name="SSLServerCertificate"
value="../resources/certificates/server.pem" />
<param name="SSLCertificatePassword" value="password" />
<param name="SSLClientCertificateMandatory" value="true" />
</Listen>
<Listen name="AsynchronousSSL">
<param name="ServerSocket" value="com.ilex.sock.PureTLSServerSocket" />
<param name="SSLFlag" value="true" />
<param name="SSLRootCertificate"
value="../resources/certificates/root.pem" />
<param name="SSLServerCertificate"
value="../resources/certificates/server.pem" />
<param name="SSLCertificatePassword" value="password" />
<param name="SSLClientCertificateMandatory" value="true" />
</Listen>
</Listens>
The configuration defines 4 ‘<listen>’ ports that correspond to the various security server’s ports and
modes. The SSL protected ports are those named ‘AsynchronousSSL’ and ‘SynchronousSSL’, whilst
the other two are ‘AsynchronousNoSSL’ and ‘SynchronousNoSSL’.
In addition, a port can be restricted to listen on a particular network interface by specifying an IP
address in the ‘<Address>’ tag of the corresponding ‘<Listen>’ section.
The security server can be addressed on both the standard and SSL ports at the same time, the
choice depends principally on the implemented architecture (whether the network segment between
the security server and the agent(s) is/are secure or should the communications be encrypted across
SSL).
6.3.2 Changing the Sign&go activation key

The Sign&go product activation key can be found in the <key> element of the server.xml file.
<Server>
<Config>
...
<Key></Key>
...

Sign&go
This element can be modified in cases where the key is renewed.
6.3.3 Logging security server activity

The security server has the ability to log various events during the authorisation and authentication
phases. These logs can be useful during the debugging phase of various security policies. The
security server uses log4j to log its various events. The name of the log4j Logger associated with the
security server is gateway:
<logger name="gateway" additivity="false">

<level value="debug"/>
<appender-ref ref="LogFile"/>
</logger>
The event logs are stored in the file securityservertrc.log situated in the server/logs sub-directory of
the Sign&go installation directory. The name of the file is specified by the LogFile appender:
<appender name="LogFile" class="org.apache.log4j.RollingFileAppender">

<param name="File" value="logs/securityservertrc.log"/>
<param name="MaxBackupIndex" value="9"/>
<param name="MaxFileSize" value="1MB"/>
<param name="threshold" value="debug"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %c{1} - %m%n"/>
</layout>
</appender>
6.3.3.1 Changing the security server’s logging level

To change the logging level of the security server, locate the required logger and modify its level
parameter to any of the following values:
 fatal, for all event logs having a level of FATAL,
 error, for all event logs having a level of ERROR or FATAL,
 warn, for all event logs having a level of WARN, ERROR or FATAL,
 info, for all event logs having a level of INFO, WARN, ERROR or FATAL,
 debug, for all event logs.
Example configuration of a logger:
<logger name="myloggername" additivity="false">

<level value="debug"/>
<appender-ref ref="myappendername"/>
</logger>
Generic loggers exist for logging various items of information:
Generic loggers
gateway.Authentication Collects the event logs of the security server’s processing of authentications
and updates of authentication credentials.
gateway.Authorization Collects the event logs of the security server’s processing of authorisations.

Sign&go
Generic loggers
gateway.Cache Collects the event logs of the security server’s components “cache-hits”.
gateway.DtProvider Collects the event logs relating to the loading of Sign&go specific
configuration data from LDAP/DSML.
gateway.Infos Collects the event logs of the security server’s processing of various events,
notably: behaviours, criteria, mappings…
gateway.Protocol Collects the event logs relating to the communication protocol between
agents and the security server. The debug level displays the XML
request/response pairs between agents and the security server.
gateway.Request Collects the event logs relating to the various requests destined for the
security server.
Note: In order to use logs when there are concurrent requests to the security server, the server
can be configured to serialise the processing of the various log events. To do this, define the
parameter <SerializeRequest> to be true. Attention: activating this functionality switches the
security server to mono-thread mode and has a large impact on its performance.
6.3.3.2 Changing the log configuration in real-time

Changes to the logging configuration can be taken into account in real-time, or more precisely the
log4j configuration data in the server.xml file can.
The <RefreshLogs> parameter controls the refresh time (in milliseconds) of the logging configuration.
It is effectively the maximum time that elapses before modifications to the server.xml file are taken
into account. If this parameter is undefined or has a value of less than 100ms, this function is disabled.
The following example illustrates how changes to the logging configuration will be effected within five
minutes of making modifications to the server.xml file:
<Server>
<Config>
...
<RefreshLogs>300000</ RefreshLogs >
...
This real-time loading of parameters only applies to the configuration of the log4j logger, in other
words the <log4j:configuration> section of the server.xml file.
Attention: The loading of the log4j configuration is subject to conditions.
The existing log4j configuration is not deleted during a reconfiguration; all of the appenders within the
new configuration file are closed but remain attached to the loggers which have not been reconfigured.
There could therefore be errors such as "No appenders could be found for logger xxx" after
reloading the configuration. If the root logger is contained in the new configuration file, then all of the
preceding appenders are reloaded.
Further information on the configuration of log4j in general can be found in Configuration page 81.
6.3.3.3 Redirecting logs to a logging console

Security server logs can be redirected to a log4j LogFactor logging console situated on the same
machine. The console is activated by removing the comments around the following line:

Sign&go

This will start the LogFactor console the next time that the security server is restarted. The console
displays the various security server event logs in the form of a table.
Note: If the console is closed, it is not possible to reopen it without restarting the security
server.
6.3.4 Changing the maximum request processing time

The maximum time allowed for a request to be processed is configurable. If the processing of a
request exceeds this time, the thread that was dealing with it will be destroyed and the request logged
to the log4j deadlock logger with a level of FATAL.
For more information on the log4j, refer to Configuration page 81.
In order to configure this parameter, edit the ‘server/genway.xml’ file.
Modify the connections’ ‘Timeout’ parameter for the port in question. The parameter is defined in
seconds.
<Relay name="SynchronousNoSSL">
<param name="Active" value="true"/>
<param name="LoadBalancing" value="false"/>
<param name="Timeout" value="600"/>
<param name="UseListen" value="SynchronousNoSSL"/>
<param name="UseFilter" value="PacketGathering"/>
<param name="UseFilter" value="SynchronousRequest"/>
<param name="UseNetwork" value="NoStack"/>
</Relay>
6.3.5 Configuring the security server’s LDAP datasource

On Windows platforms, when a Complete Install has been carried out, an OpenLDAP server is
installed. This OpenLDAP server contains the internal configuration data for Sign&go (rules, security
policies…). For issues related to integration, it can be useful to change the source of the security
server data (to have several servers point to the same LDAP server for example). The chapter
Initialising the configuration directory page 39 describes how to install a directory other than
OpenLDAP (IPlanet, Active Directory…).
6.3.5.1 Modifying the directory configuration

To modify the source of the security server data, the <DataSource> element in the security server’s
server.xml configuration file is used. This element contains the following parameters:
Parameters
JNDIUrl The LDAP directory’s connection URL. This can be a space-separated list
of connections in order to provide redundancy. The URL takes the form:
ldap://host:port where host is the machine where the LDAP server is
installed and port is the server’s listening port (3899 by default).
Example: ldap://localhost:3899
JNDIProvider Name of the Java JNDI-LDAP provider. The default value is:
com.sun.jndi.ldap.LdapCtxFactory but can be replaced by another value

Sign&go
Parameters
if a specific driver is required for connecting to the directory. In this case
refer to the driver’s documentation for more information.
SecurityProtocol Communication protocol to use for connecting to the directory. If no

protocol is specified, the communication will be open, the SSL parameter
can also be specified in order to establish a secure connection with the
directory. In both of these cases the JNDIUrl parameter must be modified
so as to connect to the directory on port 636 (the default port).
SecurityAuthentication Authentication method to implement for the directory connection: none for
an anonymous connection, simple or strong for an authenticated
connection.
DN User DN for connecting (bind) to the directory.
DNPassword The user’s password for connecting to the directory.
Base Base DN in the directory where the Sign&go data is situated. For example:
ou=signandgo,dc=ilex-si,dc=com.
IsLDAPProvider This parameter must be set to true.
Trace Setting this parameter to true displays log messages relating to LDAP
requests made by the security server to the ILEX logging console
(WIN_TRC.exe). The value false stops the logging.
BlacklistActivated Blacklisting of connections. Two values are allowable: true or false.

If true then any connection, defined in the JNDIUrl parameter, which fails
during establishment of the connection will be blacklisted.
By default, a URL is blacklisted for 2 minutes (120000 milliseconds).
This parameter can be modified by defining the system property
ilex.jndi.connectionpool.blacklistTime with a value in milliseconds.
6.3.5.2 Modifying the LDAP connection pool

The Sign&go security server relies on the standard Java LDAP connection pool (Java 1.4 JNDI). For
details, refer to the standard Java documentation.
This connection pool requires no specific configuration for operation with Sign&go. However it can be
re-configured if required. Refer to the online documentation at the following address for more
information: http://java.sun.com/products/jndi/tutorial/ldap/connect/config.html
6.3.5.3 Modifying the JNDI properties

The LDAP directory properties can be modified by adding elements under the <DataSource> tag.
These elements take the following form:
<property_name>property_value</property_name>
Where:
 property_name is the name of the added property. For example: javax.naming.batchsize,
java.naming.security.sasl.autorizationId
 property_value is the value of the added property. For example:
2, dn:cn=administrators,ou=groups,o=sun,c=us

Sign&go
The properties will automatically be added to the JNDI context during establishment of the LDAP
connection. It is thus possible to provide complementary information in order to modify the
communication behaviour (DIGEST authentication, referral handling, aliases…).
For more information refer to the JNDI documentation available online at the following address
http://java.sun.com/products/jndi/tutorial/beyond/env/overview.html
6.3.6 Asynchronously loading of the configuration

The security server loads the configuration asynchronously into a dynamic cache from the
configuration directory. Two parameters in the server.xml configuration file enable control of this
asynchronous loading:
 CheckConfigTime, the time in milliseconds between each configuration update,
 MaxUpdateTime, the maximum time that the configuration update can take.
As a consequence, every CheckConfigTime milliseconds, the security server launches a security
server configuration update process. If the configuration has changed, it is reloaded in its entirety. It
has up to MaxUpdateTime milliseconds to be reloaded. If the reloading is successfully carried out, the
new data is implemented otherwise the configuration remains as it was before the updating process.
6.3.7 Storing/Encrypting the configuration

In order to achieve high availability, the security server can store its configuration on the local disk in
the form of an encrypted or unencrypted .xml file. Two parameters apply to this configuration file:
 ConfigurationCacheEncryptionKeyFile,
 ConfigurationCacheEncryptionMode.
6.3.7.1 ConfigurationCacheEncryptionKeyFile
Path and filename of the file containing the key to use for encrypting the configuration file saved on the
disk.
If this parameter is not specified, the value that will be used is keyencryptconfig.bin.
If this file does not exist, it will be automatically created.
This key is used in conjunction with a second key contained in the program to encrypt the
configuration saved on the disk. A key other than the automatically generated one can be used.
6.3.7.2 ConfigurationCacheEncryptionMode
Method of encryption to be used for the Sign&go configuration saved on the disk. Possible values are:
 false: no encryption,
 not present or any value other than false: Triple DES encryption with a key defined in the file
ConfigurationCacheEncryptionKeyFile and the key hard-coded in the program.

Sign&go
7 USING THE PRE-CONFIGURED OPENLDAP DIRECTORY

This chapter only concerns Windows platforms on which a full installation has been carried out.
7.1 Access
The OpenLDAP directory delivered with Sign&go on the Windows platform is configured to start as a
Windows system service and listen on the local machine (127.0.0.1) on port 3899.
7.1.1 Changing the OpenLDAP port

For the directory to be accessible from a machine other than the one that it is installed on, make the
following changes:
 Run regedit.
 Modify the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\sngOpenLDAPServer_
v5.0\Parameters\Urls by ldap:// a.b.c.d:x/
Where a.b.c.d, is the IP address that is authorised to access the directory, and x, is the TCP port.
 Restart the Windows service associated with this OpenLDAP instance.
Note: To allow all machines on the network to access the directory, specify the IP address
0.0.0.0. If the access port is modified, do not forget to modify the Sign&go access
configuration. See Configuring the security server’s LDAP datasource page 57.
7.1.2 Deleting a service

 Run the PatchService.exe executable in the bonus\ PatchService_Release_1.2 directory on the
Sign&go CD-Rom.
 Click Connect/Refresh.
 Select the service to be deleted: ILEX Sign&Go v5.0 OpenLDAP.
 Click Delete the service.
7.2 Generating certificates

The Sign&go Complete Install provides an OpenLDAP server complete with generic certificates for
testing the TLS mode. Certificates can easily be generated with the aid of the scripts provided. To do
this operation manually, refer to the following paragraphs.
Note: The certificates installed with OpenLDAP are for testing purposes. It is HIGHLY
recommended that these certificates are NOT used in a production environment because the
password that protects the key is known (“secret”) and the “Common Name” is not the name
of the server. It is equally advised that self-signed certificates are not used either because
there is no trusted certification path. Generation of this type of certificates is outside the scope
of this document, for further information consult the following URL:
http://www.openldap.org/pub/ksoper/OpenLDAP_TLS_howto.html
Generating certificates to activate the TLS mode consists of obtaining various certificates:
 a certificate from a certification authority (recommended),
 an OpenLDAP server certificate (mandatory),
 a client certificate if the server verifies the client identities (optional).

Sign&go
In the following paragraphs, the generation of certificates for three different entities is described:
 OpenSSL,
 Microsoft,
 Verisign.
7.2.1.1
OpenSSL certificates
All of the following commands are executed with the aid of openssl.exe situated in the openldap sub-
directory of the Sign&go installation.
1. Creating the certification authority (CA):

 generate the CA’s private key:
openssl genrsa -des3 -out ca.key 1024

 generate the key’s corresponding CA:
openssl req -config openssl.cnf -new -x509 -days 365 -key ca.key -out
ca.crt
The CA is found in the ca.crt file and the corresponding key in ca.key.
 to integrate this key with the pre-configured OpenLDAP directory, copy ca.crt to the file
CA_Certificate.pem in the openldap sub-directory of the Sign&go installation.
2. Creating the self-signed root certificate (certificate server):

 generate the root certificate’s (certificate server’s) private key:
openssl genrsa -des3 -out my-server.key

 generate the key’s corresponding root certificate (certificate server):
openssl req -config openssl.cnf -new -key my-server.key -out my-server.csr
Note: Complete the field cn with the full DNS name (Fully Qualified Domain Name) of the server
as it will be used in the URL of the hosted resources (for example: www.mysite1.com).
 sign the root (server) certificate by the CA:
openssl x509 -req -days 365 -in my-server.csr -CA ca.crt -CAkey ca.key
-CAcreateserial -out my-server.cert
The signed certificate server is in my-server.cert and the associated private key in my-server.key.
 to integrate this certificate with the pre-configured OpenLDAP directory, copy the file my-
server.cert to SRV_Certificate.pem in the openldap sub-directory of the Sign&go
installation.
 copy the CA (ca.crt) and the root certificate’s private key (my-server.key) into the file
SRV_KEY.pem in the openldap sub-directory of the Sign&go installation (copy my-
server.key+ca.crt SRV_KEY.pem).
7.2.1.2
Microsoft certificates
On Windows platforms, certificates can be created and used by installing Microsoft Certificate
Services. Certificates and therefore private keys are stored in an internal certificate store but can be
copied by exporting them.

Sign&go
Note: To export the private key, choose the appropriate option during creation of the certificate
request.
1. Installing Microsoft Certificate Services

 To install Microsoft Certificate Services, please proceed as follows:
 start Add/Remove programs from the control panel (Start -> Settings -> Control Panel ->
Add/Remove programs),
 click on the icon situated on the left hand side titled Add/Remove Windows
components.
 select the component Certificate Services.
 click Next.

 under Certification Authority types, select Stand-alone root CA (selected by default).

 click Next. Attributes of the Certification Authority will be requested during the installation:
The Microsoft Certificate Services is a Web application. Once installed, it is accessible by the URL:
http://hostname/certsrv/.
2. Creation of a Certificate Authority (CA)

The certification authority is created during the installation of the service but its certificate and private
key remain stored in the certificate store.
To recover the certificate, proceed as follows:
 open the URL http://hostname/certsrv (where hostname is the name of the machine
hosting the Certificate Services),
 select Retrieve the CA certificate or revocation list and click the Next button,
 on the next page, select the certificate to be displayed,
 select the Base 64 encoded radio button,
 click on the Download CA certificate link,
 select Save this file to disk in the File download dialogue box that is displayed, then
click OK,
 save the file.
The resulting file contains the Certification Authority’s certificate in the PEM format.
Sign&go
3. Creating the self signed root certificate (certificate server)

Obtaining a certificate consists of completing a certificate creation request and submitting it to
Certificate Services. The resulting certificate is then recovered along with its private key and converted
into the PEM format. Proceed as follows:
 open the URL http://hostname/certsrv/,
 select Request a certificate and click Next,
 select the Advanced request option and click Next,
 on the following page, select Submit a certificate request to this CA using a form and
click Next.
 complete the form that is displayed:
Note: In the Name field, enter the name of the server as it will be used in the URL of the hosted
resources (for example: www.mysite1.com).
 in the field Intended Purpose, select Server Authentication Certificate,

 select the check box Mark keys as exportable,
 click Submit,
 a new page appears indicating: ”Your certificate request has been received. However
you must wait for an administrator to issue the certificate you requested”.
The certificate requests are held until an administrator gives their agreement for them to be created.
Proceed as follows:
 run the Certification Authority by clicking Start -> Programs -> Administrative Tools ->
Certification Authority. The following window is displayed:

Sign&go
 select the folder Pending Requests,

 in the right hand pane, right-click on the pending request and in the context-sensitive
menu select All Tasks followed by Issue. The selected entry will disappear from the list
and the certificate has been created. Exit the program once all certificates have been
created,
Once the certificate has been created, return to the Web interface (http://hostname/certsrv/) and
proceed as follows:
 select Check on a pending certificate,
 click Next, the following window is displayed:
 in the displayed list, select the certificate to be retrieved.

 click Next and the following window will be displayed:

Sign&go
 click Install this certificate and the following window will be displayed:
At this point the certificate has been installed. The Certificates administration tool is used to retrieve
the certificate. This utility is installed as follows:
 click Start, then Run, type mmc and click OK. The Microsoft Management Console is
displayed,
 click on the File menu then Add/Remove Snap-in,
 in the dialogue box that appears, click the Add button,
 another dialogue box is displayed, select the Certificates entry in the list and click the
Add button. If you are logged on as an administrator, select My user account and click
Finish,
 click Close to exit the list of snap-ins and then OK to close the Add/Remove snap-in
dialogue box,
 click on the menu Console, then Save as…. Type a name (such as Certificates for
example) and click Save. The Administration Tools directory is proposed by default for
saving the console.
Once the certificates administration tool is installed proceed as follows to retrieve the certificate:
 start the MMC (as described above). Open the previously saved console by clicking on
the File menu, then Open, select the .msc file that was saved above and click Open. In
the left hand pane, expand the Certificates – Current user branch followed by Personal
then Certificates. The list of created certificates appears in the right hand pane:
 double-click on the certificate to be retrieved. A dialogue box will open displaying the
certificate’s properties. To save the certificate to a file, select the Details tab:

Sign&go
 click on the Copy to file… button,

 click Next and the following will appear:
 select Yes, export the private key. The following dialogue box will appear:

Sign&go
 select the options as indicated above followed by Next,

 the dialogue box that is displayed requests a password to protect the file because it will
contain the private key. Enter a password if desired and click Next,
 enter a filename and click Next followed by Finish,
 the following dialogue box indicates successful exportation of the certificate and its key:
The file just created is in PKCS12 format with the extension .pfx. To be able to use it with the Proxy, it
must be converted into a PEM format file. As previously mentioned the file is in PKCS12 format and
contains the following elements:
 the server certificate,
 the server certificate’s private key,
 the Certification Authority’s certificate.
The conversion of the file to the PEM format is carried out with the aid of openssl.exe situated in the
openldap sub-directory of the Sign&go installation directory.
 Certification Authority certificate

The following command creates a pem file containing the Certification Authority’s certificate (normally
only used once):
openssl pkcs12 -in server00acme.pfx -out acmeCA.pem -cacerts -nokeys
This command requires the password that protects the original file (the .pfx file in this example) to be
entered. The command creates the file acmeCA.pem in the PEM format.
Copy and rename the file acmeCA.pem to CA_Certificate.pem in the openldap sub-directory of the
Sign&go installation directory.
Sign&go
 Certificate Server
The following command creates a .pem file containing the server certificate and its private key:
openssl pkcs12 -in server00acme.pfx -out server00.pem -clcerts

This command first of all requests the password that protects the original file (the .pfx file in this
example), followed by the password that will protect the .pem file that will be created. The command
creates the file server00.pem in the PEM format.
Copy and rename the file server00.pem to SRV_KEY.pem in the openldap sub-directory of the
Sign&go installation.
Copy and rename the file server00.pem to SRV_Certificate.pem in the openldap sub-directory of
the Sign&go installation.
7.2.1.3 Verisign certificates

The method of obtaining a certificate from an external certification authority (CA) is as follows:
 creation of the keys and the certificate request (Certificate Signing Request, CSR) which will
contain the public key, the identity and other attributes of the certificate,
 submission of the request to a certification authority,
 retrieval of the certificate issued by the certification authority,
 conversion of the files to PEM format for use by the OpenLDAP directory.
1. Creating the keys and certificate request

The creation of the certificate request is carried out with the aid of openssl.exe situated in the
openldap sub-directory of the Sign&go installation. Proceed as follows:
 enter the following command:
openssl req -config openssl.cnf -new -out serverreq.pem

This command creates: a certificate request in the file serverreq.pem, a private/public key pair with
the private key saved in the file privkey.pem in PEM format with no password.
2. Submitting the request to the certification authority

Send the contents of the file serverreq.pem to Verisign (or any other certification authority) to request
the certificate.
3. Recovering the certificate issued by the certification authority

The certification authority should return two certificates:
 the requested server certificate,
 the certification authority’s self-signed certificate.
If these two files are not in the PEM format, use openssl.exe to convert them.
Use the following command to convert a DER format certificate to a PEM format:
openssl x509 -in Fichier.der -inform DER -out Fichier.pem -outform PEM
 copy the PEM file containing the certifcation authority’s certificate to CA_Certificate.pem
in the openldap sub-directory of the Sign&go installation,
 copy the file containing the server certificate to SRV_Certificate.pem in the openldap
sub-directory of the Sign&go installation,

Sign&go
 copy the PEM file containing the server certificate’s private key to SRV_Key.pem in the
openldap sub-directory of the Sign&go installation.
7.2.2 Configuration
To implement TLS mode, the configuration file slapd.conf must be modified. This file is located in the
openldap sub-directory of the Sign&go installation.
Edit the file and locate the following section:
#TLSVerifyClient never
#TLSCertificateFile "./SRV_Certificate.pem"
#TLSCertificateKeyFile "./SRV_KEY.pem"
#TLSCACertificateFile "./CA_Certificate.pem"
Replace it by:
TLSVerifyClient never
TLSCertificateFile "./SRV_Certificate.pem"
TLSCertificateKeyFile "./SRV_KEY.pem"
TLSCACertificateFile "./CA_Certificate.pem"
The various parameters are as follows:

 TLSVerifyClient, specifies what checks to perform on an incoming client connection (never
implies no authentication, communication will be encrypted however),
 TLSCertificateFile, specifies the file containing the server’s certificate,
 TLSCertificateKeyFile, specifies the file containing the private key of the certificate specified by
the TLSCertificateFile parameter,
 TLSCACertificateFile, specifies the file containing the certification authority’s certificate.
For more detailed information, consult the documentation at the following address:
http://www.openldap.org/pub/ksoper/OpenLDAP_TLS_howto.html.
After modifying and saving the slapd.conf file, restart the OpenLDAP directory.
7.2.3 Operation
When the directory is operating in TLS mode, a password is requested each time it starts:
This password corresponds to the pass phrase of the certificate used to activate TLS mode.
Note: Entry of this password can be avoided by saving it in the Windows registry under the key
HKEY_LOCAL_MACHINE\SOFTWARE\Ilex\OpenLDAP\PemPhrase of type REG_SZ with the
certificate’s pass phrase as its value. ATTENTION: THIS INFORMATION is on the server IN
PLAIN TEXT and can be remotely viewed with the default Windows settings. It is recommended
that precautions are taken to restrict access to this information.

Sign&go
8 SIGN&GO SECURITY SERVER AUDIT MESSAGES

This chapter describes the security server’s auditing capabilities in terms of:
 the audit information that can be obtained,
 the auditing configuration,
 modifying the configuration,
Auditing is characterised by the collection of information linked to the surveillance of processes which
is then stored on a medium. The monitored security server processes are those of authorisation and
authentication.
8.1 Audit information

The security server records information on the success and failure of user authorisation and
authentication operations. Some types of information are common to different processes and others to
the operation of only one type.
8.1.1 List of information items

Below is a table summarising all of the security server information that can be collected and saved.
Note: Character strings in the following table are restricted by the Sign&go Administration to
containing the following characters: “0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz -_ àâéèêëîïôùûç ,@\\/()”.
Item Internal Name Description Permitted values

Agent name x-sngagentname Name of the agent Character string limited to the format
requesting the specified in the Sign&go
authentication or administration.
authorisation.
Example: AG01
Agent TCP port x-sngagenttcpport TCP port of the agent Number between 0 and 65535.
filtering access to the
resource.
Authentication x-sngauthenticationstate Authentication status of the One of the following character

state token. strings:
TOKEN_AUTHENTICATION
TOKEN_NEW_AUTHENTICATION
TOKEN_NEW_PERSISTANT_AUT
HENTICATION,
NEW_PERSISTANT_AUTHENTICA
TION.

Sign&go

Behaviours x-sngbehaviorsapplied List of the behaviours Series of comma-separated
applied applied during the character strings limited to the format
authorisation. specified in the Sign&go
administration.
Example:
access_authorised,redirect,add_hea
der
Client IP x-sngclientipaddr IP Address of the client Character string of the form:

address requesting access to a aaa.bbb.ccc.ddd
resource.
Résolution du nom de
Client
x-sngclienthostname machine de l’adresse x-Chaîne de caractères.
Hostname
sngclientipaddr
Client TCP port x-sngclienttcpport TCP port of the client Number between 0 and 65535.
requesting access to a
resource.
Date x-sngdatelong Date and time serving as a Number (of data-type ‘long’).
temporal reference for the
logs.
Main directory x-sngdirectoryname Name of the directory where Character string, limited to the
the identifier x-snguserid is format specified in the Sign&go
located. administration.
Example: dir_ldap_3
Zone name x-sngdomainname Name of the zone Character string, limited to the
associated with the format specified in the Sign&go
resource. administration.
Example: domain-name
Authentication x-sngfirstdirectoryname Name of the directory on Character string, limited to the

directory which the user is format specified in the Sign&go
authenticated. administration.
Example: dir_sql1
Initial user ID x-sngfirstuserid The identifier of the user Character string.

authenticated on the
authentication directory.
Log message x-snglogmsg Message associated with Character string.

the log type.

Sign&go
Log type x-snglogtype Log type. Positive integers:

 from 1 to 999:
authentication successful,
 from 1001 to 1999:
authorisation successful,
 from 5001 to 49999:
authentication failed,
 from 50001 to 99999:
authorisation failed.
Directory x-sngmappingdirectory Name of the directory Character string, limited to the

mapping mapping that was used to format specified in the Sign&go
find the user’s entry in the administration.
main directory.
Example: mapdir_test
Policy trust x-sngpolicytrustlevel Level of confidence required Positive integers up to 999999999.

level for access to the resource.
Example: 8
Processing x-sngproctime Time taken in milliseconds Number (of data-type ‘long’).

time to process the authorisation
or authentication.
Requested x-sngresourceasked Name of the resource Character string representing a URL.

resource requested by the user.
Protected x-sngresourceregistered Name of the resource Character string representing a URL.

resource protected by Sign&go that
corresponds the closest to
that requested by the user.
Name of the application
accessed by the user as Character string
x-sngapplicationname
defined in the security policy.
Response TTL x-sngresponsettl The Time-To-Live of the Integer.

security server’s response.
Rules applied x-sngrulesapplied List of the rules that have Series of comma-separated
been applied. character strings, limited to the
format specified in the Sign&go
administration.
Example: rule1, general_rule,
rule_test3
Schema x-sngschemadescription Description of the schema Character string, limited to the

description that was used to format specified in the Sign&go
authenticate the client administration.
Example: ”Authentication by
smartcard”

Sign&go
Schema level x-sngschemalevel Authentication level of the Positive integers up to 999999999.

schema used for the
authentication. Example: 10
Schema x-sngschemalistdirectories The list of directories Series of comma-separated

directory list associated with the character strings, limited to the
authentication schema. format specified in the Sign&go
administration
Example: directory_ldap1,
directory_sql3,
administration_directory
Schema list x-sngschemalistname Name of the authentication Character string, limited to the
list used to authenticate the format specified in the Sign&go
user. administration
Example: schema_list1
Schema name x-sngschemaname Name of the authentication Character string.

schema used to
authenticate the user. Example: schema_cps
Indicates whether the

x-sngschemapersistent Boolean. 0 if TRUE, 1 if FALSE.
authentication is persistent.
Schemas used x-sngschematab List of the schemas used to Series of comma-separated

authenticate the user. character strings.
Example: schema_kerberos,
schema_cps, schema_trusted.
Schema type x-sngschematype The type of schema that Character string.

authenticated the user.
Example: ”Smartcard authentication”
Secure link x-sngsecure Indicates whether the link is Boolean. 0 if true, 1 if false.
secured.
HTTP headers x-sngtabhttphdr List of the HTTP headers Series of comma-separated

used by the client to access character strings of the form:
the protected resource.
{header1;value1},{header2;value2},
{header3;value3}
Resource list x-sngtabresources List of the resources Series of comma-separated

protected by the agent. character strings of the form:
"{//pctest.test.com/portal/administrati
on/*},{//pctest.test.com/portal/user/*},
{//pctest.test.com/portal/confidential/
*}"
Token content x-sngtokencontent Contents of the Sign&go Character string.

token presented by the
user.

Sign&go
New token x-sngtokencontentnew Contents of the token after Character string.

content a new authentication of the
user.
Token level x-sngtokenlevel Authentication level of the Positive integers up to 999999999.

token.
Example: 10
This variable is dependant
on a preceding
authentication.
New token x-sngtokenlevelnew Authentication level of the Positive integers up to 999999999.

level token after a new
authentication. Example: 10
This variable is dependant

on a preceding
authentication.
Token initial x-sngtokenlogin The user’s initial login in the Character string.
user ID token.
New token x-sngtokenloginnew The user’s login after a new Character string.
initial user ID authentication.
Token serial x-sngtokenserial The serial number of the Character string.

No token.
New token x-sngtokenserialnew The serial number of the Character string.

serial No token after a new
authentication.
Token TTL x-sngtokenttl The Time-To-Live of the Integer.

token.
New token TTL x-sngtokenttlnew The Time-To-Live of the Integer.

token after a new
authentication.
Token user ID x-sngtokenuserid The user’s identifier (DN) in Character string.

the token (as retrieved from
the authentication
directory).
New Token x-sngtokenuseridnew The user’s identifier (DN) in Character string.

user ID the token (as retrieved from
the authentication directory)
after a new authentication.
User ID x-snguserid The user's identifier (DN) Character string.

retrieved from the
authentication directory.
Workstation x-sngshared The type of workstation: Character string.

type dedicated or shared.
Value: true or false

Sign&go
eSSO account x-sngaccounttype The type of account used Character string.

type (NORMAL, DELEGATED,
SHARED).
eSSO account x-sngaccountowner The name of the account Character string.

owner owner (if a shared or
delegated account) used for
an application.
Source x-sngsourceid Allows specifying the name Character string.

of the component that
requests the log: either
‘eSSO’ or ‘Gina’
eSSO Account x-sngaccount The name of the account Character string.

name or used by the eSSO or the
Windows Windows domain.
domain
logged event x-snglogevent Corresponds to the type of Character string.

event: logon, logoff, lock,
unlock, application login,
delegation issued etc.
8.1.2 Item details

All the preceding items of information cannot be recorded simultaneously for each operation. Some of
them are specific to authentications and others to authorisations.
8.1.2.1 Authentication
This information provides answers to the following questions:
 Who tried to authenticate themselves?
 By which means?
 At what time?
 What was the result?
Who Which means When Result
x-sngagentname x-sngschemaname x-sngproctime x-snglogtype
x-sngschematype date x-snglogmsg
x-sngtokencontent x-sngschemadescription time x-sngtokencontentnew
x-sngtokenserial x-sngauthenticationstate x-sngdatelong x-sngtokenserialnew
x-sngtokenlevel x-sngschemalevel x-sngtokenlevelnew
x-sngtokenttl x-sngschemalistname x-sngtokenttlnew

Sign&go
Who Which means When Result
x-sngtokenlogin x-sngscheamtab x-sngtokenloginnew
x-sngtokenuserid x-sngschemapersitent x-sngtokenuseridnew
x-sngschemalistdirectories
x-sngclientipaddr x-sngfirstdirectoryname
x-sngclienttcpport x-sngmappingdirectory
x-sngagenttcpport x-sngdirectoryname
x-sngclienthostname x-sngfirstuserid
x-snguserid
8.1.2.2 Authorisation
 Who tried to access a resource?
 Which one?
 How?
 When?
Who What How When Result
x-sngtokencontent x-sngresourceasked x-sngtabhttphdr date x-snglogtype
x-sngtokenserial x-sngresourceregistered x-sngsecure time x-snglogmsg
x-sngtokenlevel x-sngapplicationname x-sngresponsettl x-proctime
x-sngtokenttl x-sngtabresources x-sngdatelong
x-sngtokenlogin x-sngpolicyname
x-sngtokenuserid x-sngdomainname
x-sngagentname x-sngpolicytrustlevel
x-sngagenttcpport x-sngrulesapplied
x-sngclientipaddr x-sngbehaviorsapplied
x-sngclienttcpport
x-sngclienthostname

Sign&go
8.1.2.3 Workstation component authorisations
From version 4.3, the Web authorisation logs are differentiated from the Workstation component
authorisation logs. In order to do this, a new audit table has been created which is named
WK_AUTHORIZELOG.
 Which one?
 When?
Who What When Result

x-sngtokenlogin x-sngshared x- sngdatelong x-snglogtype
x-sngclientipaddr x-sngapplicationname x-snglogevent
x-sngaccount
x-sngclienthostname
x-sngsourceid
x-sngprofile
x-sngaccountowner
x-sngaccounttype
x-sngapplicationlogin
8.1.2.4 Administration console actions
From version 4.3, the logging of actions within the Administration Console has been added. In order to
do this, a new audit table has been created which is named ADMINLOG.
 When?
What When Result

x-snglogmsg x-sngdatelong x-snglogmsg
x-snglogtype
Note: The x-snglogtype parameter will contain a value allowing the tab where the user’s action
was performed (example: configuration, directory, authentication, authorisation, variables,
SAML, rights) to be identified.

Sign&go
8.1.3 Main information items

In both cases, authorisation and authentication, the principle items of information are the date of the
log (with its time) and its type. Its type is a numeric value and is represented by x-snglogtype.
The numeric values indicate:
 from 1 to 999, a successful authentication,
 from 1001 to 1999, a successful authorisation,
 from 5001 to 49999, a failed authentication.
 from 50001 to 99999, a failed authorisation.
The different values of x-snglogtype (Log Type) and their meaning are:
Value Log Type
1 "Authentication succeeded"
The authentication of the user is OK.
10 "New Authentication"
Authentication of the user has been carried out.
20 "New persistent authentication"
Authentication of the user has been carried out and its type is ‘persistent’.
30 "Token authentication"
The token presented by the user has been authenticated.
40 "New token authentication"
The token presented by the user was not suitable. A new authentication has been carried out
resulting in the token being updated.
50 "New token persistent authentication"
The token presented by the user is not sufficient so a new authentication has been carried out
and its type is ‘persistent’. The token has been updated.
1001 "Authorisation succeeded"

Access to the resource has been authorised.
5001 "Authentication failed"

Authentication of the user has failed.
5002 "Authentication not allowed due to license restrictions".

Authentication of the user has failed because the license would not allow it.
50001 "Authorisation failed".

Access to the resource has been refused.
8.2 Statistics information

The Sign&go security servers collect various information about their operation: memory use, response
times… This information is stored at regular intervals and enables surveillance of the servers in order
to improve performance.
8.2.1 Information items

The statistical information is provided in several different forms:

Sign&go
1. counter
The value takes the form of an integer number:
 Count : the value
2. statistic
A group of values is stored:
 Last: the last value stored;
 Avg: the average of all the values provided,
 Min: the minimum value,
 Max: the maximum value,
 Samples: the number of samples permitting calculation of the Avg, Min and Max values.
3. time
A time in the form HHhMMmSSs, ou HH represents the le number of hours, MM the number of
minutes and SS the number of seconds
Here is an example of the statistics log:
2004-05-28 21:41:53,666 [used-threads] Last:18 Avg:19 Min:15 Max:25

Samples:8
2004-05-28 21:41:53,666 [Handled-requests] Count:37066
2004-05-28 21:41:53,666 [used-memory] Last:1807280 Avg:2412586 Min:1762248
Max:4213896 Samples:8
2004-05-28 21:41:53,666 [JNDI-connections] Last:2 Avg:1 Min:0 Max:11
Samples:55672
2004-05-28 21:41:53,666 [Authentication-process] Last:291 Avg:436 Min:20
2004-05-28 21:41:53,666 [Bad-Requests-format] Count:5
2004-05-28 21:41:53,666 [Standard-connections] Count:37066
2004-05-28 21:41:53,666 [Request-time-processing] Last:10 Avg:191 Min:0
2004-05-28 21:41:53,666 [Active-TCP-Connections] Last:0 Avg:3 Min:0 Max:17
Samples:74132
2004-05-28 21:41:53,666 [Execution-time] 1h24m30s
The following table groups all the statistical information that can be recorded by the security server.
Name Type Description

Standard-connections Counter Number of TCP/IP connections established to the security
server’s standard listening port since start-up.
SSL-connections Counter Number of TCP/IP connections established to the security
server’s SSL listening port since start-up.
Active-TCP-connections Statistic Average number of simultaneous TCP/IP connections
established with the security server. This value includes both
standard and SSL connections. Last contains the number of
connections at the time of the last sampling.
JDBC-connections Statistic Average number of JDBC connections established with the
database. Last contains the number of connections at the
time of the last sampling.
JNDI-connections Statistic Average number of JNDI connections established with the
LDAP directory. Last contains the number of connections at
the time of the last sampling.

Sign&go
Name Type Description

Authentication-process Statistic Average time (in milliseconds) taken to carry out an
authentication procedure.
Authentication-processing-errors Counter Number of authentications having failed due to external
errors (directory connection problems, script errors…).
Authorisation-process Statistic Average time (in milliseconds) taken to carry out an
authorisation procedure.
Authorisation-processing-errors Counter Number of authorisations having failed due to external errors
(directory connection problems, script errors…).
Handled-request Counter Number of requests that have been processed since starting
the server.
Request-processing-errors Counter Number of request processing errors. This value
corresponds to the number of system errors that have
occurred since starting the security server. Information
concerning these errors in available in the security server’s
operating logs with levels of ERROR and FATAL.
Bad-requests-format Counter Number of “illegal” requests made to the security server
since it started. This value corresponds to TCP/IP
communications with the server that have invalid message
formats.
Insufficient-license Counter Number of times that a user sees their authentication
refused due to the maximum number of users defined in the
product license being exceeded.
Concurrent-users Statistic Average number of simultaneous users. Last contains the
number of simultaneous users at the time of the last
sampling.
Unauthorized-client-requests Counter Number of requests sent by non-authorised clients
(unknown agent name, wrong pass phrase, bad IP address).
The security server cuts communication with the agent and
increments the counter.
Request-time-processing Statistic Average time taken by the security server to process a
request. The processing time is taken as being from the start
of reading the request up to the sending of the reply.
Execution-time Temps The security server’s execution time. This value indicates
the amount of time since the security server was started.
used-threads Statistic Average number of threads used by the security server.
Last contains the number of active threads at the time of the
last sampling.
used-memory Statistic Average amount of memory (in bytes) used by the security
server. Last contains the number of bytes used at the time
of the last sampling.
8.2.2 Frequency of statistics sampling

The security server captures the statistics at regular intervals. The capture frequency is configurable
by modifying the security server’s server.xml configuration file in the installation’s server sub-
directory. Define the StatisticsLogInterval parameter to indicate the time in seconds between
captures.
By default, the statistics are captured every 5 minutes.

Sign&go
<StatisticsLogInterval>60</StatisticsLogInterval>
8.3 Configuration
The Sign&go security server audit information can be stored on a given media in various ways. To
configure this, modify the server’s server.xml configuration file situated in the installation’s server
sub-directory. More detailed information is available in the Modifying the configuration page 89.
Recording of the statistics is carried out with the aid of the open source log4j. Documentation relative
to this open source project is available at the URL: http://jakarta.apache.org/log4j/docs/index.html.
The following section describes log4j and gives some configuration examples.
8.3.1 log4j overview

The open source log4j enables recording of information on different types of media (mail, database,
files, network…) with various formats (W3C Extended Log, syslog protocol, database format,
proprietary format…) whilst remaining as flexible as possible.
The three essential components of the log4j solution are:
 the Logger which receives the information,
 the Appender component which interfaces with the storage medium,
 the Layout component which formats the information.
These components belong to the org.apache.log4j package.
8.3.1.1 org.apache.log4j.Logger
The logger is the entry point for the processing of the audit messages.
The log4j project constructs a Logger tree. The name of the Logger defines its tree. A Logger’s name
is derived from that of its immediate superior followed by a “.” character then its own name. The “root”
Logger is inferred. The following diagram illustrates the naming of a logger in terms of its tree
structure:
a.b a.b.z
root a
a.c
d
This tree structure enables refining the granularity of the information to be recorded.
For example, we want to audit process A which has two principal tasks, task1 and task2. We would
equally like to distinguish between these two tasks, in other words log the activity of one of them to a
database and the other to a file.
Each task is audited independently. Therefore each task is associated with a different Logger.
All the activity of process A is audited, which includes the preceding tasks. The task Loggers are
dependant on process A’s Logger.
The corresponding tree structure is therefore:

Sign&go
A.task1
root A A.task2
A is the name of process A’s Logger, A.task1 that of task1 and A.task2 that of task2. If we wanted
to separate the auditing of task1, we would only need to configure Logger A.task1A.
Each item of information can be recorded with varying levels. The base levels arranged in order of
increasing importance are:
 debug, to elaborate on the operation of a process,
 info, to give information on the operation of a process,
 warn, to give warnings on the operation of a process,
 error, to give errors on the operation of a process,
 fatal, to alert to errors that put the operation of a process in danger.
The Loggers can filter the level of information to be recorded. The most important (or highest) levels
are filtered last.
8.3.1.2 org.apache.log4j.Appender
To be able to record the messages arriving at the Logger, the Logger is associated with one or more
Appenders.
An Appender is a component that is responsible for delivering the Logger information to its destination.
Destinations can be an e-mail alert, one or several files, a database, a network protocol… In order to
configure recording of the messages, each Appender has its own parameters.
An Appender can take charge of messages from other Loggers. In addition, by the use of an
“appender additivity” flag, the Logger has the ability to send messages to the one immediately superior
to it within the tree. This ability is only possible if the flag has the value true (true is the default value).
In this case, the Appenders of the immediately superior Logger will also process the Logger’s
messages.
The following diagram illustrates the additivity and plurality of Appenders:
A.task1
(additivity=true)
information
info1
root A
(additivity=true)
information
info1 logged
Appender 1
A.task2
(additivity=false
Appender Appender ) information
root A info2
information
info2 logged
information information
info1 logged info1 logged Appender 2
information
info2 logged
Appender 3
This additivity parameter is no applicable to the root logger because it is the origin of all loggers.

Sign&go
8.3.1.3 org.apache.log4j.Layout
An Appender can call upon a Layout in order to format the messages prior to them being saved.
Depending on the implementation, the Layout can also have parameters. The most common Layout is
org.apache.log4j.PatternLayout. This Layout has only one parameter: ConversionPattern.
A special Layout has been conceived for the needs of Sign&go: ilex.log.W3CLayout. This Layout
enables transforming information passed in the form of an ilex.log.LogObject (which is nothing more
than a series of key-values) into the extended W3C format. This Layout has only one parameter
FieldList.
8.3.2 General configuration

The auditing configuration has been added to that of Sign&go. The Sign&go configuration file is
server.xml which is located in the server sub-directory of the Sign&go installation and is in XML
format. For auditing actions in the Sign&go Administration Console, the configuration file is located in
the Administration Console application’s directory: /WEB-INF/classes/log4j.xml.
To configure the logs, the server.xml file must have a particular XML format and be capable of
refering to log4j, therefore it must contain the following information:
<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
The two previous lines must be located at the beginning of the server.xml file.
The configuration of logging is specified by the XML element <log4j:configuration>. The subsidiary
XML nodes are specified by the <appender>, <logger>, <root> elements representing the Appender,
Logger, and the Logger root objects respectively.
8.3.3 Configuration of the root Logger root

The <root> element corresponds to the root Logger root; it has the same parameters as the other
Loggers (see the following paragraphs).
8.3.4 Configuration of a Logger

The Loggers are represented by the <logger> element. Configuration of a Logger is made as follows:
<logger name="loggerName" additivity="false">

<level value="info"/>
<appender-ref ref="MyAppenderRef"/>
</logger>
Where:
 name is the Logger name as defined by its position in the tree structure,
 additivity defines whether the immediately superior Logger’s Appender will process this Logger’s
messages as well. Permissible values are true and false,
 value is the value of the element <level>, which defines the log level at which messages will be
recorded. All messages above this severity will be stored. The permissible values are debug,
info, warn, error et fatal,
 ref is the reference of this Logger’s Appender. The configuration file will be searched for the
Appender having this name in order to locate its configuration parameters.

Sign&go
The permissible Logger names (i.e. for the name parameter) for Sign&go audit information are:
 logsngsrv,
 logsngsrv.logauthorization,
 logsngsrv.logauthorization.ok,
 logsngsrv.logauthorization.ko,
 logsngsrv.logauthentication,
 logsngsrv.logauthentication.ok,
 logsngsrv.logauthentication.ko.
The permissible Logger names for statistical information consist of gateway.system.statistics followed
by the name of the targeted statistic:
 gateway.system.statistics,
 gateway.system.statistics.Standard-connections,
 gateway.system.statistics.SSL-connections,
 gateway.system.statistics.Active-TCP-connections,
 …
For more information, see the Modifying the configuration section page 89.
8.3.5 Appender and Layout configuration

The Appender’s configuration parameters are defined under the <appender> element. The
configuration of an Appender has the following general format:
<appender name="appenderName" class="MyAppenderClass">

<param name="myAppenderParameter1" value="myValue1"/>
<param name="myAppenderParameter2" value="myValue2"/>
<param name="myAppenderParameter3" value="maValue3"/>
...
<layout class="MyLayoutClass">
<param name="myLayoutParameter1" value=" myValue1"/>
...
</layout>
</logger>
Where:
 name of the <appender> element: is the name and therefore the reference of the Appender,
 class of the <appender> element: is the name of the Appender’s class,
 <param> child-element of the <appender> element: is the parameter specific to the Appender.
This parameter is sent to the Appender during its instantiation,
 class of the <layout> element: is the name of the Layout’s class,
 <param> sub-element of the <layout> element: is the parameter specific to the Layout. This
parameter is sent to the Layout during its instantiation,
A Layout must depend upon an Appender, which is why its configuration is in the Appender section.

Sign&go
8.3.6 Appender and Layout examples

Here are some examples of Appenders and Layouts that can be used to audit the security server. This
is not an exhaustive list.
8.3.6.1 “Converted character string” Layout type

This Layout serves to format an audit message in a conventional form adding information about the
process or the circumstances at the time the message was issued. It instantiates the
org.apache.log4j.PatternLayout class and has a mandatory parameter ConversionPattern which
defines a conversion pattern to be applied to the output from the Appender.
The pattern is composed of literal text and format control expressions called conversion specifiers.
Each conversion specifier starts with a “%” character and is followed by optional format modifiers and
a conversion character. The conversion characters specify the type of data to display (category,
thread name, date, priority…) whereas the format modifiers define how the data should be displayed.
For example, suppose that a “ConversionPattern” has the value:
%-5p [%t]: %m%n:
 %-5p, during formatting of the message, this specifier is replaced by the message priority and is
left-justified in a field having a width of 5 characters,
 %t is replaced by the thread name that generated the audit message,
 %m is replaced by the audit message (before formatting),
 %n is replaced by an End Of Line character,
 “[“, “]“and “:“ are literal text characters and are therefore displayed ‘as is’. They are not
conversion characters.
8.3.6.2 "W3C extended log" Layout type

This Layout formats a series of name-value pairs in the W3C extended log format. It instantiates the
ilex.log.W3CLayout class and has a single parameter FieldList. More information on the extended
log format is available at the following URL: http://www.w3.org/TR/WD-logfile.html.
The FieldList parameter’s value is a comma separated list of fields to be displayed. The audit log
messages will be formatted with the fields in the order specified by the parameter. In order for all the
fields in the parameter to be displayed by the Layout, they must exist in the original audit log message.
The W3CLayout Layout only formats messages corresponding to ilex.log.LogObject objects.
Take the following example:
<layout class="ilex.log.W3CLayout">
<param name="FieldList" value="date,time,x-snglogtype,x-snglogmsg"/>
</layout>
The Appender associated with this Layout converts the audit log messages to W3C extended log
format composed of the date, time, x-snglogtype and x-snglogmsg fields (as long as they exist in
the original message).
8.3.6.3 "Console" Appender type

This Appender displays the audit log messages in the system console in the format generated by the
associated Layout. It instantiates the org.apache.log4j.ConsoleAppender class and the parameter
threshold defines the minimum category level of the messages to be displayed.

Sign&go
<appender name="MyAppenderRef" class="org.apache.log4j.ConsoleAppender">

<layout ...>
...
</layout>
</appender>
8.3.6.4 "Rolling File" by file-size Appender type

This Appender saves messages in the desired format to a series of files. It instantiates the
org.apache.log4j.RollingFileAppender class and has several parameters.
Messages are written to a file until it reaches the maximum size defined by the parameter
MaxFileSize at which point it is closed and recording continues in a new file. Each file is closed when
MaxFileSize is reached. Once the number of backup files defined by the parameter
MaxBackupIndex is reached, the earliest created file that exists is deleted thereby maintaining the
maximum number of files to that defined by the parameter.
The following is an example configuration:
<appender name="MyAppenderRef"
class="org.apache.log4j.RollingFileAppender">
<param name="File" value="myFile.txt"/>
<param name="MaxBackupIndex" value="5"/>
<param name="MaxFileSize" value="1MB"/>
<layout ...>
...
</layout>
</appender>
8.3.6.5 "Rolling File" by time interval Appender type

This Appender saves messages in the desired format to a series of files. It instantiates the
org.apache.log4j.DailyRollingFileAppender class and has several parameters.
At a regular time interval a new log file is created This Appender can create a new file each month,
each week, each day, twice a day, every hour or every minute. The saving of files is carried out
automatically by log4j by suffixing the log file names with the date and time.
The DatePattern parameter defines the frequency at which the files are saved and takes the following
values:
Frequency
'.'yyyy-MM The rotation of the logs is carried out at the end of each month; the file-
name is suffixed with the year followed by the month number (1 to 12).
'.'yyyy-ww The rotation of the logs is carried out at the beginning of each week (on
Saturday evening); the file-name is suffixed with the year followed by the
week number (1 to 52).
'.'yyyy-MM-dd The rotation of the logs is carried out at midnight each day; the file-name is
suffixed with the year followed by the month number and day number (1 to
31).
'.'yyyy-MM-dd-a The rotation of the logs is carried out at midday and midnight each day; the
file-name is suffixed with the year followed by the month number, the day
number and finally AM or PM.

Sign&go
'.'yyyy-MM-dd-HH The rotation of the logs is carried out every hour; the file-name is suffixed
with the year, the month number and the hour (1 to 24).
'.'yyyy-MM-dd-HH-mm The rotation of the logs is carried out every minute; the file-name is suffixed
with the year, month number, the hour, and finally the minute (0 to 59).
<appender name="MyAppenderRef"
class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="myFile.txt"/>
<param name="DatePattern" value="'.'yyyy-ww"/>
<layout ...>
...
</layout>
</appender>
8.3.6.6 "Database" Appender type

This Appender saves audit log messages in a database. Use of this Appender requires that a
database with a table capable of storing the messages has been pre configured. The Appender
instantiates the ilex.log.W3CJDBCAppender class and operates without a Layout but the
messages must correspond to the ilex.log.LogObject object.
<appender name="MyAppenderRef" class="ilex.log.W3CJDBCAppender">

<param name="Driver" value="sun.jdbc.odbc.JdbcOdbcDriver"/>
<param name="URL" value="jdbc:odbc:mydatasource"/>
<param name="User" value="mylogin"/>
<param name="Password" value="password"/>
<param name="EscapeStr" value=""/>
<param name="Sql" value="insert into myW3CTable(column_type,column_msg)
values(!?x-snglogtype?!,'!?x-snglogmsg?!'"/>
</appender>
In this example, an SQL query will save values into the column_type and column_msg columns in
the myW3CTable table of the jdbc:odbc:mydatasource data-source. These values correspond to
the x-snglogtype and x-snglogmsg parameters whose signification is detailed in the Audit
information on page 70.
Note: The SQL queries issued by this Appender can be logged. The queries are re-directed to
the log.W3CJDBCAppender Logger with a trace level of debug. The Appender’s parameters are
documented in the Sign&go Java Documentation located in the /doc/javadoc sub-directory of
the Sign&go installation.
8.3.6.7 "SMTP" Appender type

This Appender sends formatted e-mails to a specified address. It instantiates the
org.apache.log4j.net.SMTPAppender class and has several parameters.
<appender name="MyAppenderRef" class="org.apache.log4j.net.SMTPAppender">

<param name="SMTPHost" value="smtp.ilex.fr"/>
<param name="From" value="signandgo@ilex.fr"/>

Sign&go
<param name="To" value="adminsignandgo@ilex.fr"/>

<param name="Subject" value="Audit Sign&go"/>
<param name="threshold" value="error"/>
<layout class="...">
</layout>
</appender>
In this example, the Appender will send audit log messages having the severity error in the form of
e-mails to the SMTP host smtp.ilex.fr for transmission to adminsignandgo@ilex.fr. The e-
mail will have the subject of Audit Sign&go and be from signandgo@ilex. The body of the
message will be the original log formatted by the associated Layout.
Note: Care must be taken when configuring this type of appender in order not to sent too many
messages by setting the value of ‘threshold’ too low (the debug and info levels are generally
not recommended).
8.3.6.8 "Network" Appender type

This Appender sends the log message objects to a remote server. It instantiates the
org.apache.log4j.net.SocketAppender class and has several parameters. The destination
host and TCP port are specified by the RemoteHost and Port parameters respectively. The
LocationInfo parameter specifies whether localisation information should be sent to the remote
host and can have the values true or false.
<appender name="MyAppenderRef" class="org.apache.log4j.net.SocketAppender">

<param name="RemoteHost" value="localhost"/>
<param name="LocationInfo" value="true"/>
<layout ...>
...
</layout>
</appender>
8.3.6.9 "NT events" Appender type

Messages can equally be sent to the NT event log system. It instantiates the
org.apache.log4j.nt.NTEventLogAppender class and has several parameters.
All of the messages recorded by this Appender can be inspected with the Windows Event Log Viewer
and will have the source name specified by the Source parameter.
<appender name="MaRefAppender"
class="org.apache.log4j.nt.NTEventLogAppender ">
<param name="Source" value="SourceName"/>
<param name="threshold" value="error"/>
<layout ...>
...
</layout>
</appender>
8.3.6.10 "Syslog" Appender type

This appender sends, via UDP datagrams, messages formatted by the configured Layout to a Syslog
service hosted either locally or on a remote machine.
The destination host is specified by the SyslogHost, parameter using either a DNS name or IP
address.
Sign&go
The appender instantiates the org.apache.log4j.net.SyslogAppender class.

<appender name=" MaRefAppender"

class="org.apache.log4j.net.SyslogAppender">
<param name="SyslogHost" value="MySyslogServer"/>
<param name="Facility" value="LOCAL1"/>
<param name="Header" value="true"/>
<layout ...>
...
</layout>
</appender>
8.4 Modifying the configuration

8.4.1 Default mode
By default, the audit log messages are saved in rolling text files in W3C extended format using the
RollingFileAppender file Appender with the W3CLayout W3C extended log Layout (see the
previous section: Configuration on page 81).
The permitted fields of the FieldList parameter are indicated in the tables in the Item details on
page 75. Statistics messages are recorded in separate rolling text files in the following format:
Date - INFO - Name of the statistic - [Name of the statistic] Message
8.4.2 Logger names

The Logger enabling the recording of authorisations is logsngsrv.logauthorization, the
Logger enabling the recording of authentications is logsngsrv.logauthentication, and the
Logger enabling the recording of statistic is gateway.system.statistics.
Note that there is a sub-group of statistics Loggers formed by gateway.system.statistics
suffixed by the name of the statistic, it is thus possible to isolate various measurements in order to
study them.
8.4.3 Configuration
For reasons of Sign&go security server auditing requirements, this configuration can be modified.
All that is required is to modify the logsngsrv.logauthorization,
logsngsrv.logauthentication and gateway.system.statistics Loggers’ Appenders
and/or Layouts with the help of this chapter’s preceding paragraphs and the online documentation
provided by log4j.
If the auditing of authorisations and authentications is carried out on the same media, the logsrvsng
Logger will be used. Conversely, the granularity of the logs can be refined by using:
 the logsngsrv.logauthentication.ok Logger for successful authentications only,
 the logsngsrv.logauthentication.ko Logger for failed authentications only,
 the logsngsrv.logauthorization.ok Logger for successful authorisations only,
 the logsngsrv.logauthorization.ko Logger for failed authorisations only.

Sign&go
8.5 Modification to auditing in version 4.3

The auditing application has be modified in order to display information faster. To make this possible,
a primary key (sngid) has been added to all the tables.
8.5.1 Migration
Important: A backup of the database must be performed before migrating.
A script has been provided that will add the new primary key to existing authentlog and authorizelog
tables. This script is in the /logsng/Migr_up_to_4.2 directory which is located at the root of the Security
Server’s installation directory. Scripts exist for the three most popular databases.
Next, to add the two new wk_authorizelog (see 8.1.2.3) and adminlog (see 0) tables if desired, the
scripts in the /logsng/Migr_4.2_to_4.3 directory corresponding to the database need to be executed.
8.5.2 New Installation

In this case, implementation of all the audit tables is performed by the script corresponding to the
database. This script is located in the /logsng directory located at the root of the Security Server’s
installation directory.
8.5.3 Configuring audit logs for the administration console

The following file must be modified in order to configure audit logs for the administration console:
/SIGNANDGO_INSTALL_DIRECTORY/tomcat/webapps/signandgo/WEB-INF/classes/log4j.xml
Within this file, a logger named "sign&go.tech.audit_admin" is defined in "info", but no appender is
associated with it (they are commented out by default).
Un-commenting the desired appenders (Console, LogAdmin or Database) will allow administration
actions to be logged according to the selected appender(s).

Sign&go
9 ANNEXES: INSTALLATION OF .WAR FILES

Sign&go has four WEB applications:
 signandgo, administration application (signandgo.war),
 auth, authentication application (auth.war),
 logs, authentication and authorisation auditing application (logs.war),
 selfregistering, application managing the secondary creditations (selfregistering.war),
 saml
 samlv2
 Sign&go, previous administration application which now redirects to the signandgo application
(for compatibility with previous versions of Sign&go).
The Sign&go Web applications can be deployed on a server other than the administration server
(other than the Tomcat 5 application server installed with Sign&go). In this case the .war files in the
sub-directory wars are used.
This annex explains this type of deployment on three popular Web servers:
 Tomcat 4-5,
 WebSphere 5.1,
 WebLogic 8.1.
Note: The signandgo application requires the server/server.xml configuration file in order to
function. Once the application’s .war file has been installed, copy the server.xml file to the
application server machine then modify the application’s WEB-INF/web.xml file to point to the
location of server.xml.
9.1 Tomcat 4-5

9.1.1 Installation on Windows
The deployment is carried out via the Tomcat Manager page accessible from the Tomcat server’s
welcome page.
Once Tomcat has been started:
1. go to the default page (http://localhost:8080/),
2. click on the Tomcat Manager link on Tomcat’s welcome page and then enter the username
and password of a user that has management or administration rights on the server (i.e. has
the admin or manager role). By default the username is admin with the password admin. The
various Tomcat user accounts are defined in the file /conf/tomcat-users.xml in the
Tomcat installation directory,
3. the Tomcat Web applications management page gives access to all of the applications
deployed by the application server,
4. to include the Sign&go Web application, enter the .war file’s pathname in the Select WAR
file to upload field in the page’s Deploy section or use the Browse… button to locate the file
and then click the Deploy button,
5. if the operation is successful, a message will be displayed in the Message field that appears
at the top of the page and the application will appear in the Applications list with its
pathname, state and a set of commands for managing it.

Sign&go
The application will become available at the address

http://localhost:Port/application_name/ where Port is Tomcat’s TCP port number and
application_name is the name of the deployed Sign&go application.
By looking in Tomcat’s Webapps sub-directory, it can be seen that the application has been deployed
in a directory having the same name as the application.
Reminder: The signandgo application needs the file server/server.xml in order to operate. Do
not forget to indicate the path of this file in webapps/signandgo/WEB-INF/web.xml and restart
the application by clicking on the Stop and then Start links in Tomcat’s Web applications
management page.
9.1.2 Installation in console mode on Linux

Go to the webapps directory where Tomcat was installed and copy the .war file into it. To deploy the
Web application, simply stop and restart the Tomcat server.
/TOMCAT_DIR/bin/shutdown.sh
/TOMCAT_DIR/bin/startup.sh
A sub-directory having the name application-name is then created in the webapps directory, where
application-name is the filename of the .war file that was previously copied.
not forget to indicate the path of this file in webapps/signandgo/WEB-INF/web.xml and restart
the application by clicking on the Stop and then Start links in Tomcat’s Web applications
management page.
9.1.3 Websphere 5.1

Deployment of the application is carried out via Websphere’s administration console:
 click on Install an Application within the Applications menu,
 enter the pathname of the .war file and the context root then click Next,
 on the bindings page click Next,
 if a security message appears, take a note of it and click Continue,
 complete the various pages of the installation steps, to accept default settings, just click Next,
 verify that the contents of the Summary panel correspond to the required configuration and click
Finish to start installation of the application,
 once the installation has finished, click on Manage Applications.
 the application that has just been installed can be seen in the list as application_name_war,
where application_name is the name of the deployed application. It will currently be in a Stopped
state, the Websphere configuration must be saved before the application can be started,
 click on the Save menu then click Save.
 once the configuration has been saved, click on Enterprise Applications in the menu and select
the application to be started before clicking the Start button. The application should now be
available via a Web browser:
http://ixwebsphere:9080/application_name/
Where ixwebsphere is the name of the server and 9080 is the access port.

Sign&go
not forget to indicate the path of this file in
WebSphere_DIR/AppServer/installedApps/IxWebsphere/signandgo_war.ear/signandgo.war/WE
B-INF/web.xml then stop and restart the application via the Websphere administration
interface.
9.1.4 WebLogic 8.1

The deployment is carried out in two stages:
 firstly, locate the .war file and decompress it in a directory,
 once the file is decompressed modify the configuration files, notably for the signandgo application
(see ‘Reminder’ above).
The second stage of the application’s installation is made via the Weblogic console:
 click on the Web Application Modules menu then on Deploy a new Web Application Module,
 enter the pathname to the directory containing the decompressed file. Select the checkbox
corresponding to the application to be deployed then click on Target Module.
 enter the name of the application, and click Deploy,
 the application should now be deployed. To access it, enter its URL in a Web browser.
http://Server:port/application_name.
Where server is the name of the server and port is the access port.

Security Server Installation and Configuration Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security Server Installation and Configuration Guide

Uploaded by

Copyright:

Available Formats

SECURITY SERVER INSTALLATION

AND CONFIGURATION GUIDE

Copyright Ilex 2015. All rights reserved.

Ilex Security server installation and configuration guide Page 2/93

TABLE OF CONTENTS ....................................................................................... 3

5.3 Integration with ADAM ...................................................................................... 44

Ilex Security server installation and configuration guide Page 4/93

Ilex Security server installation and configuration guide Page 5/93

The following diagram illustrates these three elements:

Ilex Security server installation and configuration guide Page 6/93

2.2.1 Installation of the security server

2.2.2 Installation of the configuration directory

Ilex Security server installation and configuration guide Page 7/93

3 INSTALLING THE SIGN&GO SECURITY SERVER

3.1 Windows 2003 compatibility

3.2 Windows Vista compatibility

In addition, on some systems, ‘Data Execution Prevention’ mode must be de-activated:

3.3 Launching the installer

3.3.1 Graphical mode

3.3.2 Console mode

You will then be presented with a screen similar to the following:

Ilex Security server installation and configuration guide Page 9/93

Unpacking the JRE...

Preparing CONSOLE Mode Installation...

3.4 Choice of language

3.4.1 Graphical mode

Select the desired language then click OK.

3.4.2 Console mode

CHOOSE LOCALE BY NUMBER:

Ilex Security server installation and configuration guide Page 10/93

3.5.1 Graphical mode

3.5.2 Console mode

You may cancel this installation at any time by typing ’quit’.

PRESS <ENTER> TO CONTINUE:

Ilex Security server installation and configuration guide Page 11/93

3.6 License agreement

3.6.2 Console mode

a. To modify wholly or partly the program.

b. To decompile or reconstitute the program.

c. For registered users, it is strictly forbidden to transmit their registered

TO CONTINUE PRESS <ENTER>:

Ilex Security server installation and configuration guide Page 12/93

NO LIABILITY FOR INDIRECT DAMAGE. ILEX assumes no responsibility in any

TO CONTINUE PRESS <ENTER>:

DO YOU ACCEPT THE TERMS OF THIS LICENSE AGREEMENT (Y/N): y

3.7 Product activation key

Ilex Security server installation and configuration guide Page 13/93

3.7.1 Graphical mode

3.7.2 Console mode

Enter key filename:

3.8 Choice of components

Ilex Security server installation and configuration guide Page 14/93

3.8.1 Graphical mode

Once the desired option has been selected, click Next.

Ilex Security server installation and configuration guide Page 15/93

3.8.2 Console mode

Please choose the feature set to be installed by this installer.

->1- Standard install

Please choose the Components to be installed by this installer.

Ilex Security server installation and configuration guide Page 16/93

ENTER A COMMA-SEPARATED LIST OF NUMBERS REPRESENTING THE COMPONENTS

3.9 Choice of directory

3.9.1 Graphical mode

3.9.2 Console mode