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/

Tivoli Access Manager Certificate Management

This is the best Technote I found from IBM on TAM Certificate management. Keeping a copy here in case the original note gets deleted. http://www-01.ibm.com/support/docview.wss?uid=swg21516849

What needs to be considered in a TAM environment regarding certificate expiration?

All Tivoli Access Manager (TAM) components rely on SSL. At a minimum the components use SSL to communicate with each other. They can also use SSL to communicate with other client applications, registry servers, etc. The keystores used in a TAM environment are usually either CMS key database format (kdb) or a Java keystore (jks). When using a kdb file, as long as you're using a .sth file to stash the password of your kdb file, you can use the "/opt/PolicyDirector/sbin/dispkdb -f <kdb file>" command to view the contents of a kdb file. This will show you the expiration date of the keystore password (if you see 1969 then it means password is not set to expire) as well the certificate information such as the names, labels, date created, and expiration dates. This allows you to easily see when a certificate will expire.Most people do use the sth file, but if you are not using it and have the kdb password configured in your config file (webseal, ivmgr, etc) then you will need to use the gsk7ikm, gsk7cmd, or gsk7capicmd command to open the kdb file with your password and check the expiration dates that way.With WebSEAL, there is one kdb file which you will need to monitor for sure, which is the following (by default, from the webseald-<instance>.conf)

webseal-cert-keyfile = /var/pdweb/www-default/certs/pdsrv.kdbThis is where you store your own certificates, so you need to manage those.Also, if you're using SSL to your LDAP server, you should monitor the kdb file specified in the [ldap] "ssl-keyfile" attribute of your webseald-default.conf, ivacld.conf, ivmgrd.conf, etc.Also on each of the TAM components you will find another kdb file defined in the [ssl] "ssl-keyfile" attribute (for example "default-webseald.kdb"). This is the keystore used to talk to the TAM components. You do not need to worry much about these since they are mostly self-managing, and their passwords are randomly generated at configuration time (meaning that nobody knows what the password is). By default, they will refresh themselves before the certificates expire automatically. However, these updated certificates cannot be used until the process is restarted. To avoid problems, the process must be restarted before the certificate in memory expires.

Basically, when one of the components is configured, such as webseal, the Policy Server will create a certificate for it to use. The lifetime of this certificate is controlled by the [ssl] "ssl-cert-life" attribute in the ivmgrd.conf file (by default 365 days). When webseal sees that the certificate is past it's half-life (6 months by default) then it will ask the policy server to generate a new one for it. However webseal needs to be re-started to start using this new certificate, before the old one expires. As such, it's recommended to re-start the processes at least twice for every "ssl-cert-life"...or every 6 months by default.If your processes are not restarted regularly, you can change the ssl certificate lifetime to something longer (2yrs, 5yrs, 10yrs, etc) so that you don't need to re-start the processes later on.- To change the Policy Server's certificate and certificate lifetime to say 5 yrs (1826 days) you can run the following command on the Policy Server system..../opt/PolicyDirector/sbin/mgrsslcfg -chgcert -l 1865and then re-start the policy server (pd_start restart)- In order to get a new certificate with a new certificate lifetime on the WebSEALs, pdacld, etc, you would need to refresh the certificate for EACH instance.../opt/PolicyDirector/sbin/svrsslcfg -chgcert -f cfg_file [-A admin_id] [-P admin_pwd]-f cfg_file Configuration file path and name. This is a requiredparameter and should be your webseald-<instance>.conf, ivacld.conf, ivmgrd.conf, etc.-P admin_pwd The Tivoli Access Manager Administrator password. If thisparameter is not specified you will be prompted for thepassword.-A admin_id The Tivoli Access Manager administrator name. If notspecified, this parameter defaults to "sec_master"and then -restart the processes.Other than this, you will also need to keep an eye on your LDAP server's certificates for expiration. For Tivoli Directory Server (TDS) this kdb file would be configured in your LDAP instance's ibmslapd.conf under the ibm-slapdSslKeyDatabase attribute.Lastly, if you need to look at jks file for certificates (used if you have a java application using TAM, WAS, etc) you can view the contents of the jks with the following command...keytool -list -v -keystore <jksfilename> -storetype JCEKShit enter for passwordIn the properties file created by the SvrSslCfg command, if you have "certrefresh=true" then this certificate will update itself once the application is re-started after the halfway point of the certificate's life (ssl-cert-life in ivmgrd.conf).

Monitoring these certificates is the responsibility of the administrators. Your solution could be as simple as putting a note on your calendar a month before a certificate is to expire, or you could decide to implement automated processes to query the kdb files regularly and notify you when a certificate will expire....it's up to each administrator to determine what is suitable for them.