Tivoli Security: Using Tivoli Access Manager for e-business with HTTPS for Authentication Only

Configuration procedure

In intranet deployments of IBM® Tivoli® Access Manager for e-business, there is often a requirement to use the HTTPS protocol for the authentication phase only, and use HTTP protocol for all other communications. Reasons for this are typically that the network is (mostly) trusted, and the performance impact of SSL is deemed unwarranted. This article describes the configuration procedure to achieve this with the WebSEAL component of Tivoli Access Manager for e-business.

Share:

Neil Readshaw (readshaw@au1.ibm.com), Senior Security Architect, IBM

Readshaw, NeilNeil Readshaw is a Senior Security Architect in the Tivoli Security Team based on the Gold Coast, Australia. In this role, Neil works with customers to define solutions using the Tivoli Security software suite, and works in an enablement role with IBM Business Partners and the IBM technical sales team in the Asia Pacific region.


developerWorks Contributing author
        level

19 July 2007 (First published 16 November 2005)

Introduction

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.

Key elements of the solution include:

  • Redirecting to a known URL after WebSEAL login
  • Sharing the user session across HTTP and HTTPS

References

  • IBM Tivoli Access Manager for e-business V5.1 - Base Administration Guide
  • IBM Tivoli Access Manager for e-business V5.1 - WebSEAL Administration Guide

Scenario

Consider an organization that has a set of Web applications deployed in the intranet. The company requires a single sign-on solution across these applications, all of which are front-ended by a single employee portal. The intranet network is largely trusted, and so the need for data privacy for all requests is not necessary. However, authentication and password management should still occur over the HTTPS protocol so that passwords are never visibly transmitted.

The company has chosen 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.

About IBM Tivoli Access Manager

IBM Tivoli Access Manager is a robust and security rich policy management tool for e-business and distributed applications. It addresses the challenges of escalating costs for e-business security, growing complexity of enterprise security solutions, and the inability to implement security policies across platforms. Through its highly available centralized authorization service, IBM Tivoli Access Manager enables better management of business-critical distributed information. It provides simple, more secure access to critical information, and enhances communications with customers, business partners, and others.

IBM Tivoli Access Manager for e-business provides authentication and access control services for Web resources. The WebSEAL server, a component of IBM Tivoli Access Manager for e-business, manages access to all Web servers, regardless of their platforms. This allows an organization to centrally control their Web resources as a single, logical Web space.

IBM Tivoli Access Manager for Operating Systems provides fine-grained control of operating system resources on Linux® and UNIX® systems.

IBM Tivoli Access Manager for Business Integration provides protection for MQSeries® messages. It allows MQSeries applications to send data with confidentiality and integrity using keys associated with the sending and receiving users. The IBM Tivoli Access Manager authorization service provides access control to MQSeries-based services, restricting which users or processes can and cannot put messages on queues or get messages from queues.

IBM Tivoli Access Manager also provides application APIs to allow in-house developed applications to access IBM Tivoli Access Manager services. IBM Tivoli Access Manager supports the Java™ 2 Platform, Enterprise Edition (J2EE) standard Java Authentication and Authorization Service (JAAS) to allow native Java applications to access IBM Tivoli Access Manager for authorization decisions.

IBM Tivoli Access Manager provides a robust Web-based delegated security administration utility that allows delegate security administration to members of their online community.


Implementing the 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/<webseal-host-and-instance>/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 <PDWEB>/etc/webseald-<instance>.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://<webseal-host>:<port>/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 <PDWEB>/www-<instance>/lib/errors/<locale>/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 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 semi-trusted networks.


Code lstings

Listing 1. JavaScript code to redirect WebSEAL login to HTTPS protocol.
<script language="JavaScript">
  // do not put this code in a function and call from onLoad()
  // otherwise the error page will be fully rendered before this
  // this code is executed.
  if (location.protocol == "http:") {

    // build up the equivalent URL using HTTPS
    var newUrl = "https://" + location.hostname;

    // comment out this next line if using the default 
    // HTTPS port.  The HTTPS port configured for this
    // instance of WebSEAL will be found in the 
    // [server]https-port parameter of
    // WebSEAL's configuration file.
    newUrl += ":444";
    newUrl += location.pathname;
    newUrl += location.search;

    // redirect
    window.location = newUrl;
  }
</script>

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Security on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, Tivoli
ArticleID=98404
ArticleTitle=Tivoli Security: Using Tivoli Access Manager for e-business with HTTPS for Authentication Only
publish-date=07192007