This document provides details on the additional functionality in SIN. Its usage is dependent on the specific security requirements of particular applications, so applying the described configurations is optional for some of the products.
The information is organized under the following headings:
This section details the configurations related to the implementation of RMI in SSX.
Using SSX RMI is optional. Its usage is prompted only in cases when you must invoke the methods of remote SIN objects from different hosts.
SSX RMI on Windows uses the Apache prunsrv
service application to allow usage of SIN components for authentication as
services on remote hosts. The SSX RMI service on UNIX uses the
sagrmisrvc start script.
For more information on the prunsrv service,
see
http://commons.apache.org/daemon/procrun.html.
The information is organized under the following headings:
Check the rmisrvc folder inside SIN distribution for the following files:
install_service.bat installation script
RmiService.config file
prunsrv.exe
prunmgr.exe
Other required files
Following is a list of the required files:
sin-common.jar
sin-ssx.jar
log4j.jar
sagssxuserdb2.dll
sagssxuserdbimpl2.dll
Note:
For the correct version number, see Readme.txt
in your SIN distribution.
To use SSX RMI on Windows
Put all required JAR and DLL files into one directory together with the install_service.bat installation script.
Execute the installation script.
Note:
Executing the script installs the server, but it is not started
automatically.
Pass the URL of the sample configuration file
RmiService.config to the service. The only parameter in
this file is port = 31415. This is the port on which the RMI
server is started.
In the simplest case, the URL can point to a file in the same directory as the JAR and DLL files, but it can also be served centrally by an application server.
You can uninstall the service with > prunsrv
//DS//SAGRMI and modify the parameters of the installed service
with > prunmgr //ES//SAGRMI.
Put the sagrmisrvc start script in the usual place for the relevant UNIX (or Linux) distribution.
For example, this will be /etc/rc.d/init.d on most Linux systems.
Important:
Consult the administration manual of your Unix OS for the
right place for thesagrmisrvc file.
Check the rmisrvc folder inside SIN distribution for the following files:
The sagrmisrvc start script
The rmisrvc.sh shell script
The other required files
Following is a list of the required files:
rmisrvc.sh
sin-common.jar
sin-ssx.jar
log4j.jar
libsagssxuserdb2.so
libsagssxuserdbimpl2.so
Note:
For the correct version number, see the
Readme.txt in the SIN distribution.
To use SSX RMI on UNIX
Put all required files into the RMISRVC_BASE directory.
The start script runs the rmisrvc.sh shell script.
Set the environment variable
RMISRVC_BASE in the
sagrmisrvc script accordingly and take note of the
comments concerning further settings.
Ensure that the authdaemonPath pointing to
the sagssxauthd2 executable in your SSX installation is
set correctly in the jaas.config and that its S-bit is
set.
Important:
There is a shell script included in the SSX distribution
that can be used to perform this step.
Keep in mind the following warnings when setting up the JAAS configuration:
Many programs expect one and only one
SagUserPrincipal as the result of a successful
authentication. However, a different expected behavior cannot be excluded.
Ensure you configure the LoginContexts
accordingly.
Keeping the password in clear text in the
Subject.privateCredentials may constitute a security
risk, depending on how the Subject is handled. However,
there are use cases where the password needs to be accessible through the
Subject.
Ensure you store the password only if needed.
The communication between the
XmlServerLoginModule and the CentraSite server works
also via HTTPS. This is a requirement if the calling program and the CentraSite
server are not located on the same physical machine.
Following are the prerequisites for the HTTPS connection:
The CentraSite Apache web server must be set up to provide an HTTPS
port (set up mod_ssl).
The installed server certificate that is to be used by the Apache web
server must have the server name as the subject DName;
for example, for a server that is accessed via
https://myserver.abc.com:53443, the Subject
DName must be myserver.abc.com.
The XMLSERVER_URL must point to this HTTPS
port
There must be a trust anchor for the client to verify the server certificate. For this, preferably the issuer certificate of the server certificate must be made known to the client application.
One way of doing this is to import this issuer certificate into the cacerts file. This file is located in the jre/lib/security directory of the Java installation.
