Security Server Installation and Configuration Guide
Security Server Installation and Configuration Guide
Contact
ILEX
51 boulevard Voltaire
92600 Asnières-sur-Seine
Telephone: +33 1 46 88 03 40
Fax: +33 1 46 88 03 41
[email protected]
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).
TAB LE OF C ONT EN TS
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.
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.
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.
Note: The screen-captures presented in this document have been made on Windows, however
the installation in graphical mode is the same on Unix.
Launching installer...
->1- English
2- Français
3.5 Introduction
The following screen presents a brief introduction.
===============================================================================
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’.
To accept the terms of the license agreement, select “I accept the terms of the license agreement”
then click Next.
IT IS STRICTLY FORBIDDEN:
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:
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.
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.
To accept the terms of the license, type “y” or “Y” then press Enter.
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.
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.
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
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).
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
-------------------------
1- Security Server
2- Administration Server
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.
===============================================================================
Choose Install Folder
---------------------
Type the absolute pathname of the installation directory or keep the default. Press Enter.
Select the location for the Sign&go shortcuts, and then click Next.
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.
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’.
===============================================================================
Sign&go Administration Server Parameters
----------------------------------------
Note: The unique identifier is used during the operation of multi-domain SSO. For more
information, see the Sign&go architecture documentation.
Product Name:
ILEX Sign&go - Servers
Install Folder:
/root/Sign_and_go
Link Folder:
/tmp/install.dir.5974/Do_Not_Install
3.14 Installation
A progress bar shows how the installation is progressing.
[==================|==================|==================|==================]
[--------
/root/Sign_and_go
The login ID and password are those entered during configuration of the security server, see page 20,
In the same way, to start the security server, enter the following:
cedric@VM-DEB-31-r3:~$ /home/cedric/sng32/SecurityServer start&
The login ID and password are those entered during configuration of the security server, see page 20,
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.
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,
Ilex Security server installation and configuration guide Page 28/93
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.
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.
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.
on page 27.
# 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.
<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/*"
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.
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:
<Object name=default>
#########################################################
# configuration for the /signandgo context starts.
#########################################################
#######################################################
# configuration for the /signandgo context ends.
#######################################################
#######################################################
# Protecting the web inf directory.
#######################################################
PathCheck fn="deny-existence" path="*/WEB-INF/*"
<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="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>
ObjectType fn=force-type type=text/html
Service fn="jk_service" worker="ajp13" path="/*"
</Object>
<Object name="servlet">
ObjectType fn=force-type type=text/html
Service fn="NSServletService"
</Object>
#<Object name="servlet">
#ObjectType fn=force-type type=text/html
#Service fn="NSServletService"
#</Object>
4.6.3 Restarting
Restart the Sign&go Administration server and the IPLANET Web server.
# 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.
4.7.3 Restarting
Restart the Sign&go Administration server and Apache.
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
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
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
3. enter the following command in a Command Window (DOS) from within the C:\openldap
directory:
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"
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):
Ilex Security server installation and configuration guide Page 40/93
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:
<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.
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.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Schema Update Allowed"=dword:00000001
installschemaAD
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Schema Update Allowed"=dword:00000000
<JNDIUrl>ldap://localhost:389</JNDIUrl>
<DN>uid=Manager,ou=People,dc=ilex-si,dc=com</DN>
<DNPassword>marsupilami</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.
the modifications carried out to the server/server.xml file, such as the connection URL, base DN
and the BIND identifier are correct.
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
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).
<JNDIUrl>ldap://localhost:389</JNDIUrl>
<DN>uid=Manager,ou=People,dc=ilex-si,dc=com</DN>
<DNPassword>marsupilami</DNPassword>
<Base>ou=signandgo,dc=ilex-si,dc=com</Base>
Refer to the detailing the Security Server configuration file for more information regarding these
parameters.
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).
<JNDIUrl>ldap://localhost:389</JNDIUrl>
<DN>uid=Manager,ou=People,dc=ilex-si,dc=com</DN>
<DNPassword>marsupilami</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.
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).
<JNDIUrl>ldap://localhost:389</JNDIUrl>
<DN>uid=Manager,ou=People,dc=ilex-si,dc=com</DN>
<DNPassword>marsupilami</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.
the modification carried out to the server/server.xml file, such as the connection URL, base DN
and the BIND identifier are correct.
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.
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.
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.
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.
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.
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).
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.
Note: The Tomcat documentation can equally be consulted at the following URL:
http://localhost:8080/tomcat-docs/.
<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)):
<!--
<Connector className="org.apache.tomcat.service.PoolTcpConnector">
<Parameter name="handler"
value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
<Parameter name="port" value="8080"/>
</Connector>
-->
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.
<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.
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
debug="0" resourceName="UserDatabase"/>
<!--
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
debug="0" resourceName="UserDatabase"/>
-->
Add the following definitions just after the newly commented out block:
<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"
/>
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.
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.
<!--
This section defines the various Listen, which are server side sockets.
-->
<Listens>
...
<Listen name="SynchronousNoSSL">
<param name="Address" value=""/>
<param name="Port" value="3100"/>
</Listen>
<Listen name="AsynchronousNoSSL">
<param name="Address" value=""/>
<param name="Port" value="4100"/>
</Listen>
<Listen name="SynchronousSSL">
<param name="Address" value=""/>
<param name="Port" value="3102"/>
<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="Address" value=""/>
<param name="Port" value="4102"/>
<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).
<Server>
<Config>
...
<Key></Key>
...
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:
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.
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.
<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.
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.
<!--
<appender-ref ref="LF5"/>
-->
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.
<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>
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
Parameters
if a specific driver is required for connecting to the directory. In this case
refer to the driver’s documentation for more information.
SecurityAuthentication Authentication method to implement for the directory connection: none for
an anonymous connection, simple or strong for an authenticated
connection.
Base Base DN in the directory where the Sign&go data is situated. For example:
ou=signandgo,dc=ilex-si,dc=com.
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.
<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
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.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.
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.
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.
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).
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.
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.
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.
Note: To export the private key, choose the appropriate option during creation of the certificate
request.
The Microsoft Certificate Services is a Web application. Once installed, it is accessible by the URL:
http://hostname/certsrv/.
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).
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:
select Yes, export the private key. The following dialogue box will appear:
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.
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.
Ilex Security server installation and configuration guide Page 67/93
Sign&go
Certificate Server
The following command creates a .pem file containing the server certificate and its private key:
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,
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"
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.
Note: Character strings in the following table are restricted by the Sign&go Administration to
containing the following characters: “0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz -_ àâéèêëîïôùûç ,@\\/()”.
Agent TCP port x-sngagenttcpport TCP port of the agent Number between 0 and 65535.
filtering access to the
resource.
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
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
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
Secure link x-sngsecure Indicates whether the link is Boolean. 0 if true, 1 if false.
secured.
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.
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?
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
This information provides answers to the following questions:
Who tried to access a resource?
Which one?
How?
When?
What was the result?
x-sngtokenlogin x-sngpolicyname
x-sngtokenuserid x-sngdomainname
x-sngagentname x-sngpolicytrustlevel
x-sngagenttcpport x-sngrulesapplied
x-sngclientipaddr x-sngbehaviorsapplied
x-sngclienttcpport
x-sngclienthostname
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.
This information provides answers to the following questions:
Who tried to access a resource?
Which one?
When?
What was the result?
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.
This information provides answers to the following questions:
Who tried to access a resource?
When?
What was the result?
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.
The different values of x-snglogtype (Log Type) and their meaning are:
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.
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
The following table groups all the statistical information that can be recorded by the security server.
<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.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:
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.
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.
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:
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.
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.
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.
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.
%-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.
<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).
<appender name="MyAppenderRef"
class="org.apache.log4j.RollingFileAppender">
<param name="File" value="myFile.txt"/>
<param name="MaxBackupIndex" value="5"/>
<param name="MaxFileSize" value="1MB"/>
<param name="threshold" value="debug"/>
<layout ...>
...
</layout>
</appender>
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.
'.'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"/>
<param name="threshold" value="debug"/>
<layout ...>
...
</layout>
</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.
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 [email protected]. 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).
<appender name="MaRefAppender"
class="org.apache.log4j.nt.NTEventLogAppender ">
<param name="Source" value="SourceName"/>
<param name="threshold" value="error"/>
<layout ...>
...
</layout>
</appender>
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.
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.
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.
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.
/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.
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.
http://ixwebsphere:9080/application_name/
Where ixwebsphere is the name of the server and 9080 is the access port.
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
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.
http://Server:port/application_name.
Where server is the name of the server and port is the access port.