Thursday 19 November 2015

IBM Security Access Manager (ISAM, TAM, WebSEAL) - FORM SSO with MS-Exchange OWA

Form Single Sign On with Microsoft Exchange Outlook Web Access (OWA) using GSO
In this post, I am describing the configuration that can be helpful in performing Form Single Sign-On (FSSO) with OWA using GSO Credentials.
Following FSSO configuration parameters for are required by WebSEAL, to identify the login form and also define the configuration that will enable SSO. Save the following stanzas in a .conf file (like owa.conf)
[forms-sso-login-pages]
login-page-stanza = webmail
[webmail]
login-page = /owa/auth/logon.aspx\?replaceCurrent=*
login-form-name = logonForm
gso-resource = <Name_Of_GSO_Resource>
argument-stanza = Argument
login-form-action = /owa/auth.owa
[Argument]
destination = string:https://webmail.blogspot.com/owa
flags = string:4
forcedownlevel = string:0
username = gso:username
password = gso:password
passwordText = string:
isUtf8 = string:1
After copying contents in owa.conf file, save the file on the WebSEAL server. It is important to understand what type of junction is to be created for owa. Consider the requirement and environment to choose from the following options:
<![if !supportLists]>1.       <![endif]>Transparent standard host junction.
<![if !supportLists]>2.       <![endif]>Virtual host junction.
Transparent Standard host junction
A Transparent junction means that the name of the junctions as well as the context root of the application will be exactly same, like /owa.
A standard host junction means that the application can be accessed with name that is configured/published for webseal, and there is no restriction of hostname for the application. In other words the all standard host junctions can be accessed with a common name.
But In case of OWA, the application can be configured to use a virtual hostname. This means that you have to communicate to OWA server using specific hostname, if so is the case than in the above configuration (the destination parameter) as well as the in junction creation command (-v <virtual hostname>) highlighted above in red specify the desired virtual hostname.
Command to be used
server task <server_name> create –t <ssl/tcp> –h <hostname or IP Address of the Exchange server> –p <portname> –x –S <path_to_owa.conf> -v <virtual hostname> /owa
e.g.:
server task localhost-webseal-default create –t ssl –h 10.10.10.10 –p 443 –x –S /opt/pdweb/etc/owa.conf –v webmail.blogspot.com /owa
If you wish to add one more server to the junction,
server task localhost-webseal-default add –h 10.10.10.11 –p 443 –v webmail.blogspot.com /owa
Where,
–x is for transparent path junction
-S Form SSO configuration file
-v for virtual hostname for the server of the junction
If required you can use –s option to define a stateful junction when multiple servers are required to be added to the same junction.
Virtual host junction
To use virtual host junctions or standard host junctions is totally up to business requirement of the customer. But if the requirements say that only virtual host junctions are to be used for OWA, the here is what you need to perform.
Command to be used
server task <server_name> virtualhost create –t <ssl/tcp> –h <hostname or IP Address of the Exchange server> –p <portname> –S <path_to_owa.conf> -v <virtual hostname> webmail
e.g.:
server task localhost-webseal-default create –t ssl –h 10.10.10.10 –p 443 –x –S /opt/pdweb/etc/owa.conf –v webmail.mycompany.com /owa
If you wish to add one more server to the junction,
server task localhost-webseal-default virtualhost add –h 10.10.10.11 –p 443 –v webmail.mycompany.com webmail
Note: - If you are creating a SSL junction (regardless it’s a standard host or a virtual host junction), you must import the root certificate of the CA, which is used to sign the certificate issued for OWA. Click here to see how to add certificate of backend server in WebSEAL key database


In some cases, you might be required to add a cookie for this SSO to work. The name of the cookie is PBack and required value for this cookie is 0. Something like this.

document.cookie = "PBack=0; Path=/owa;";

This script can be added on the page which is followed after login to WebSEAL succeeds.

Saturday 14 November 2015

IBM Security Access Manager (ISAM, TAM, WebSEAL) - Add backend server certificate in WebSEAL key database

Adding backend server CA certificate in webseal key database

You can use a simple command to install the backend server CA certificate in the webseal key database. As gskit is installed as a part of ISAM installation, the gsk<Version>capicmd is easily available to the achieve this.

<GSKIT_INSTALLATION_DIR>/bin/gsk<version>capicmd -cert -add -db <location of pdsrv.kdb> –file <path of certificate to be add> -pw <password of key database> -type kdb -format <binary|ascii>

e.g.: If GSKKit version 8 is installed, and you want to add the owa_ca.der binary certificate to the key database then use the following command,

/opt/IBM/Gskkit/bin/gsk8capicmd -cert -add -db /var/pdweb/www-default/certs/pdsrv.kdb –file /home/jeelani/owa_ca.der -pw pdsrv -type kdb -format binary


Friday 13 November 2015

IBM Security Directory Integrator (ISDI, TDI) - Create New solution directory

Creating new solution directory

The following command is useful in creating a new solution directory.

<TDI_INSTALLATION_DIRECTORY>/ibmdisrv –s <path to new solution directory> -g
e.g.:  /opt/IBM/TDI/V7.1.1/ibmdisrv –s /home/jeelani/tdisol1 -g

Once the new solution directory is created, modify the following properties in solution.properties file located in the solution directory.

The highlighted port number needs to be modified so that it is unique across all the running TDI instances.
com.ibm.di.store.database=jdbc:derby://localhost:1527/$soldir$/TDISysStore;create=true
com.ibm.di.store.jdbc.urlprefix=jdbc:derby://localhost:1527/
com.ibm.di.store.port=1527

Change the port of the TDI instance from 1099. It should be unique so that remote processes can connect to TDI instance on this port. Similary modify the web server port to be unique.
api.remote.naming.port=1099
web.server.port=1098

Save the solution.properties file and start the server TDI Instance. Considering the example used above, the solution directory is /home/jeelani/tdisol1 use the following command to start the instance
(If TDI_INSTALLATION_DIRECTORY is /opt/IBM/TDI/V7.1.1)

/opt/IBM/TDI/V7.1.1/ibmdisrv –s /home/jeelani/tdisol1 –c <path to config> -r <AL Name>

If you want to start the server in daemon mode, the use the command similar to the following.

/opt/IBM/TDI/V7.1.1/ibmdisrv –s /home/jeelani/tdisol1 –d close –c <path to config> -r <AL Name>

Optionally, modify the following password properties values as described below, if you see any error regarding SSL keystore “The password is incorrect or tampered” after starting the server.

{protect}-api.keystore.password=server
{protect}-api.truststore.pass=server
{protect}-javax.net.ssl.trustStorePassword=administrator
{protect}-javax.net.ssl.keyStorePassword=administrator
{protect}-api.client.keystore.pass=administrator
{protect}-api.client.key.pass=administrator
{protect}-api.client.truststore.pass=administrator

You can use the tdisvrctl utility, to view status of the server or to start or stop config or AL's.
<TDI_INSTALLATION_DIRECTORY>/bin/tdisvrctl –h <hostname/ip address> -p <remote api port of server> -op <command like start|stop|status etc>

e.g.: /opt/IBM/TDI/V7.1.1/bin/tdisvrctl –h localhost -p 1099 -op status
/opt/IBM/TDI/V7.1.1/bin/tdisvrctl –h localhost -p 1099 -op stop –c <config_name>
/opt/IBM/TDI/V7.1.1/bin/tdisvrctl –h localhost -p 1099 -op start –c <config_name> -r <AL_Name>

IBM Security Directory Integrator (ISDI, TDI) - Extending self signed certificate's validity

The TDI Server has two certificate keystores that stores the server and admin certificates. These certificates must be extended before they expire, in order for TDI to function normally. The two TDI keystores are located in the TDI Installation directory in the following locations:
<TDI_INSTALLATION_DIRECTORY>/testserver.jks
<TDI_INSTALLATION_DIRECTORY>/serverapi/testadmin.jks

The keytool utility can be used to extend/export/delete/import certificates in the JKS keystore. Keytool is located at the following location:
<TDI_INSTALLATION_DIRECTORY>/jvm/jre/bin/keytool

The following commands shows how the validity of a certificate with alias ‘server’ can be extended by 365 days. Once the certificate’s validity is increased, it needs to be exported and imported in the Truststore as a trusted certificate.

Note:- All the paths in the following commands are relative to the TDI Installation directory. These command only affect the global testserver.jks and testadmin.jks files. If your deployment uses multiple instances of TDI, like the TDI Dispatcher for ISIM, then these commands needs to be performed for all existing instances separately. The path of the testserver.jks and testadmin.jks files will be updated. New instances created after extending the certificates have the new/extended certificates.

Extend the ‘server’ certificate in testserver.jks

jvm/jre/bin/keytool -selfcert -v -alias server -validity 365 -keystore testserver.jks -storepass server
jvm/jre/bin/keytool -export -alias server -keystore testserver.jks -storepass server -file tdiserver.crt
jvm/jre/bin/keytool -delete -alias server -keystore serverapi/testadmin.jks -storepass administrator
jvm/jre/bin/keytool -import -alias server -keystore serverapi/testadmin.jks -storepass administrator -file tdiserver.crt

Extend the ‘admin’ certificate in testadmin.jks

jvm/jre/bin/keytool -selfcert -v -alias admin -validity 365 -keystore serverapi/testadmin.jks -storepass administrator
jvm/jre/bin/keytool -export -alias admin -keystore serverapi/testadmin.jks -storepass administrator -file serverapi/tdiadmin.crt
jvm/jre/bin/keytool -delete -alias admin -keystore testserver.jks -storepass server

jvm/jre/bin/keytool -import -alias admin -keystore testserver.jks -storepass server -file serverapi/tdiadmin.crt