Using TAM-eB for HTTPS Authentication alone

Tivoli Security: Using Tivoli Access Manager for ebusiness with HTTPS for Authentication Only

This document describes how to configure the WebSEAL component of IBM Tivoli Access Manager for e-business to force users to login over the HTTPS protocol, while keeping all other application traffic over the less CPU-intensive HTTP protocol. This solution architecture is often considered for Intranet deployments of Tivoli Access Manager for e-business. It is not recommended for Internet deployments where clients are connecting over untrusted networks.

Configuration procedure:
Key elements of the solution include:
• Redirecting to a known URL after WebSEAL login
• Sharing the user session across HTTP and HTTPS

IBM Tivoli Access Manager for e-business to meet the following security requirements:
• Application traffic is served over the HTTP protocol
• The application has some unsecured, and some secured content
• URL-level security is provided by Tivoli Access Manager
• User authentication must occur over HTTPS protocol
• Users authenticate with username and password
• After successful authentication, the user is redirected to a well-known secured URL, much like a secure portal.

Solution:

The implementation of this scenario uses a new feature in Tivoli Access Manager V5.1 called login redirects. With this new function, all users are redirected to the same configured URL after successful authentication.
In this example, username and password authentication using a form has been chosen.
1. The description of this solution requires that a Tivoli Access Manager for e-business environment already be installed and configured. This includes at least one instance of the WebSEAL server.
2. Define an ACL that requires authenticated access for the chosen secured resources.
Remember that an ACL that is not attached to protected resources has no impact.
• pdadmin> acl create secure-access-for-all 
• pdadmin> acl modify secure-access-for-all set any-other rTl 
• pdadmin> acl modify secure-access-for-all set unauthenticatedl

3. Attach the ACL to the resources requiring authentication. The failure of an unauthenticated request when attempting to access this page will initiate the WebSEAL authentication processing.
The precise objects the ACL will be attached to will depends upon the configuration of the environment, namely which host the WebSEAL server is on, and which instance is being used.
• pdadmin> acl attach /WebSEAL//portal/myportal secure-access-for-all 

4. Configure WebSEAL for forms-based authentication over HTTPS protocol by setting the forms-auth parameter to https in the [forms] stanza of the WebSEAL instance's configuration file, that is /etc/webseald-.conf. Note that this indirectly prevents login over HTTP. 

5. Configure WebSEAL to share the same user session across HTTP and HTTPS protocols. This change is made in the same configuration file as in the preceding step, by setting the value of the use-same-session parameter of the [session] stanza to true. 

6. Configure WebSEAL to automatically redirect to the secure portal page over HTTP. This change is made in the same configuration file as in the preceding step, by setting the value of the login-redirect parameter of the [acnt-mgt] stanza to http://:/ portal/myportal. Note that this resource must be accessible to all users, and so it is recommended that the secure-access-for-all ACL described in the first step of this procedure be attached to this resource. 

7. Configure WebSEAL to allow for automatic redirects when using the forms authentication method. This change is made in the same configuration file as in the preceding step, by setting the value of the redirect parameter of the [enable-redirects] stanza to forms-auth. 

8. Customize the WebSEAL error page for Forbidden (HTTP status code 403) to detect if the user has made the request over HTTP, and automatically redirect to HTTPS to login. Add the code fragment from listing 1 at the top of the file /www-/lib/errors/ /38cf0427.html. 

9. Restart the WebSEAL instance. On a machine with multiple instances, ensure that the correct instance is restarted. Verifying the solution After making the changes described in the preceding section and after accessing the WebSealsecured URL over HTTP, verify the correct implementation of the solution as follows.

Verifying the solution:
After making the changes described in the preceding section and after accessing the WebSeal secured URL over HTTP, verify the correct implementation of the solution as follows.
1. Access the WebSEAL-secured URL over HTTP. 
2. WebSEAL will detect that authentication is required after consulting the access control policy, but because no authentication method is configured for use over the HTTP protocol, WebSEAL will return the error page for Forbidden (HTTP status code 403). 
3. The JavaScript added in the preceding section executes and causes the browser to redirected to the same URL over HTTPS. A browser warning about the WebSEAL server certificate might be displayed if the test certificate is still installed. 
4. The WebSEAL login form is presented, now over the HTTPS protocol.
 5. Assuming that the login succeeds, the user is then redirected to the portal URL over HTTP. A browser warning may be displayed to indicate to the user that they are switching back to an unencrypted transport. This warning can be suppressed in most browsers. 

Conclusion 
For intranet deployments, IBM Tivoli Access Manager for e-business is well-suited to provide an encrypted authentication exchange while allowing the majority of application traffic to use unencrypted HTTP protocol. This provides an ideal blend of performance and security for semitrusted networks. 

Source: https://www.ibm.com/developerworks/tivoli/library/t-tameb/

Recover a missing obfuscated file from TAM

The content is taken from the following blog post, copying it for my future reference.
http://identityandaccessmgmt.blogspot.in/2010/05/how-to-recover-missingdeleted-tam.html

Prior to TAM 5.1 the bind password was defined in the WebSEAL configuration file, in clear text (see bind-pwd). With later TAM versions for security reasons IBM introduced the *.obf file, in which the bind password is obsfucated. Here we describe the process of creating a new obf file in the event that the original file is modified/deleted.
Note that the following solution depends on the existence of a valid obf file and WebSEAL bind account elsewhere within your TAM environment.
The obf file contains the password for the account used by WebSEAL when binding to the user repository (LDAP). The obf file is created during the configuration process and should not be modified or deleted. There is no supported way to recreate the obf file, but you can borrow one from a working WebSEAL instance and synchronise the password (userPassword) using native LDAP commands.
Consider an environment that consists of two WebSEAL instances; good-webseal and bad-webseal. In our example we assume that the obf file has been removed for the bad-webseal instance. When you attempt to restart the WebSEAL it will fail as it will not be able to bind to the LDAP. The solution for this scenario is as follows:
1. Retrieve the userPassword for the good WebSEAL instance - for example:
ldapsearch –h ldap.server –p 389 –D cn=root –w password –b cn=good-webseald/tivoli.com,cn=SecurityDaemons,secAuthority=Default –s base –L objectclass=* userPassworddn: cn=good-webseald/tivoli.com,cn=SecurityDaemons,secAuthority=Default
userPassword: GOOD_PASSWORD_HASH
2. Set the bad WebSEAL bind password to the good WebSEAL password - for example:
ldapmodify –h ldap.server –p 389 –D cn=root –w password
dn: cn=bad-webseald/tivoli.com,cn=SecurityDaemons,secAuthority=Default
changetype: modify
replace: userPassword
userPassword: GOOD_PASSWORD_HASH
3. Create a bad WebSEAL obf file from the good WebSEAL obf file:
cp webseald-good.conf.obf webseald-bad.conf.obf
4. Start the bad WebSEAL
pdweb restart bad
5. The .obf file is now recovered, and the WebSEAL server is now running.

Integrate IBM Tivoli Access Manager for e-business with Lotus iNotes with LTPA Single Sign On(SSO)

This post describes the procedure for integrating IBM Tivoli Access Manager for e-business (Tivoli Access Manager) with Lotus iNotes to achieve Single Sign-On (SSO) and Single Sign-Off capability using LTPA SSO method.

The diagram above shows an integration architecture that supports the following
processes:
1. A browser request for Lotus iNotes is submitted through WebSEAL.
2. WebSEAL intercepts the request, authenticates and authorizes the user as
required.
3. WebSEAL forwards the request to the Domino Server along with a cookie
containing the encrypted LTPA token which holds the unique Distinguished
Name (DN) of the user authenticated by WebSEAL.
4. Domino decrypts the LTPA token and authenticates the DN against those in its
NAB and if a match is found access is granted.
5. The requested iNotes content for the authenticated user is sent back to
WebSEAL.
6. WebSEAL performs filtering as appropriate for the junction method then the
content is returned to the browser.

This integration scenarios is for the following product versions:
Lotus Domino Server 7.0.1, 8.0, 8.5 or 8.5.2
IBM Tivoli Access Manager Base 6.0, 6.1 or 6.1.1
IBM Tivoli Access Manager WebSEAL 6.0, 6.1 or 6.1.1
Note: Lotus iNotes might have additional constraints in the form of supported
browsers. Domino documentation for the supported version numbers should
be consulted prior to proceeding with this integration.

Before we start:: 2 point to keep in mind!


1) Configuring Tivoli Access Manager and the iNotes user
registry

-both Lotus Domino and Tivoli Access Manager use separate
user registries

-For each user in the Domino Address Book that requires iNotes, create a
corresponding user in Tivoli Access Manager

2)Generating the LTPA key file
-The LTPA key file is needed when creating the WebSEAL junction to the
Domino server, and also when creating the SSO document on the Domino server.

Option Description
-A Enable LTPA cookies
-F path_to_LTPA_keyfile Full path name location of the LTPA key file
-Z keyfile_password Password required to open the key file

Configuration Steps:

1)Tivoli Access Manager WebSEAL configuration.

option-1: copy the existing environment junction xml files to the new environment.
may need to generate a new LTPA keyfile here with help of WAs. not sure if the existing
LTPA keyfile(have to check on this),if we use the existing keyfile- make sure we know the
password to open the file.

option-2: create a new junction:-

2) Lotus Domino configuration

step-1: need the LTPA key file that was previously generated and used
when creating the WebSEAL junction. Copy this file from the WebSEAL
machine to an appropriate directory on the Domino server.

step-2: Configuring the SSO document for the Domino server
-Creating Web SSO Configuration.

step-3: Configuring the Domino server for single sign-on
To ensure that the Domino Server is properly configured for Single Sign-On.

step-4: Adding the LDAP DN to the Person documents

This step adds the LDAP DN to the User Name field of the user document. For
each user requiring SSO through WebSEAL to their iNotes database, we need to do this
configuration.

step-5: Configuring the Domino server for single sign off
To ensure that the Domino Server is properly configured for Single Sign Off.

For more details like post installation verification, uninstallation and Troubleshooting,
Please refer the attached pdf from IBM. Integration guide from IBM

Tivoli Access Manager for e-Business(TAM eB) Process Flow.

Authentication and Authorization flow charts of TAM-eB.