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/
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/
