Level: Intermediate Peter Tuton (ptuton@au1.ibm.com), Software Engineer, IBM
02 Nov 2006
Updated 12 Jul 2007 This article describes how to configure single sign-on (SSO) for SAP NetWeaver Application Server ABAP (AS-ABAP) applications by leveraging the SSO solution for IBM Tivoli Access Manager WebSEAL and SAP NetWeaver Application Server Java (AS-Java) in conjunction with the SAP logon ticket. This is achieved without the requirement of visible redirections and the TAM Global Sign-On (GSO) Lockbox.
Introduction
With the advent of SAP's NetWeaver platform, SAP technology support requires knowledge of new SAP components, including SAP NetWeaver Application
Server. SAP NetWeaver Application Server is available in two flavours: ABAP and Java, with the possibility of a combination of both. SAP NetWeaver
Application Server ABAP (AS-ABAP) is designed for applications written with SAP's well known ABAP code. The SAP NetWeaver Application Server Java,
on the other hand, is designed to make use of emerging open standards in the Java world. Both flavours play in the HTTP space. Therefore, this well
positions Tivoli Access Manager (TAM) WebSEAL to provide a single sign-on (SSO) solution to both products.
The WebSEAL SSO solution for AS-Java is simple to configure
and easily managed. The WebSEAL SSO solution for AS-ABAP,
however, requires the use of the TAM Global Sign-On (GSO) Lockbox as it does now allow for a method of SSO that is based on trust, except when using
the SAP logon ticket. The requirement for the use of the GSO Lockbox becomes cumbersome when using a combination of both AS-ABAP and AS-Java as it
adds another user registry requiring password synchronisation and management.
This article describes how to configure a method of WebSEAL SSO for AS-ABAP that does not rely on the GSO Lockbox, but instead makes use of the SAP
logon ticket generated from a WebSEAL SSO solution for AS-Java.
Scenario
Consider an environment where SAP applications are deployed using both the AS-ABAP and AS-Java. This is a likely scenario, for example,
where a customer has deployed SAP CRM, which is written using ABAP technology, and SAP Enterprise Portal, which is written using AS-Java technology.
Given the limitation of SSO options in the AS-ABAP environment that are based on trust, the identity and access management administrator (admin) is required
to configure the TAM GSO Lockbox in order to provide login credentials to the AS-ABAP. The is illustrated in Figure 1. Note the requirement to
synchronise the usernames and passwords between the GSO Lockbox and the SAP User Registry.
Figure 1. SSO to AS-ABAP and AS-Java using the GSO.
- The user requests an AS-ABAP resource via WebSEAL. Authentication credentials are provided to WebSEAL, if required.
- After successful WebSEAL authentication, WebSEAL retrieves the user's AS-ABAP credentials from the GSO Lockbox.
- The AS-ABAP credentials are sent to AS-ABAP using Basic Authentication.
- AS-ABAP authenticates the user against the SAP user registry (e.g. SAP DB) using the credentials sent via the BA header.
- After successful AS-ABAP authentication, the user is supplied with the requested AS-ABAP content, along with the SAP logon ticket.
- At a later time, the SAP logon ticket can be used to authenticate to AS-Java.
To avoid the requirement of using the GSO Lockbox, and the synchronisation of the GSO Lockbox with the SAP user registry, it's possible for the admin
to configure WebSEAL 'redirection on authentication' to force the user to access a AS-Java application first in order to obtain the logon ticket.
The AS-ABAP application would be configured for logon ticket authentication and the user would be provided a link to the AS-ABAP application from
AS-Java. Authentication in the AS-ABAP application would take place using the logon ticket obtained for AS-Java. An illustration of this configuration
is provided in Figure 2.
Figure 2. SSO to AS-ABAP and AS-Java using visible redirection but without using the GSO.
- The user requests a AS-ABAP resource via WebSEAL. Authentication credentials are provided to WebSEAL.
- After successful WebSEAL authentication, WebSEAL redirects the browser to an AS-Java application in order to obtain the SAP logon ticket.
- The browser automatically follows the redirect from WebSEAL.
- WebSEAL receives the request for an AS-Java resource and sends the username of the authenticated user in the form of an HTTP header called 'iv-user'.
- AS-Java receives the request and verifies the existence of the user in the SAP user registry.
- After successful verification, the user is supplied with the SAP logon ticket and content from the AS-Java application.
- Possibly confused, the user again requests the AS-ABAP resource. This time, the request is not redirected by WebSEAL because the user
is already authenticated.
- The request for the AS-ABAP resource is passed to the AS-ABAP server. The request contains the SAP logon ticket generated by the AS-Java.
- The SAP logon ticket is used to authenticate the user.
- After successful authentication, the user is supplied with the requested content.
Unfortunately, although we've alleviated the admin of the burden to manage the GSO Lockbox, the scenario can become confusing to some users when
they are constantly redirected after authentication to another application than the one that was requested.
Solution
The ideal solution allows for the user to access the desired SAP application, whether it be located on an AS-ABAP system or an AS-Java system,
without the confusion of redirections in addition to removing the requirement to manage the GSO Lockbox. Fortunately, this ideal solution is
available and viable. The solution makes use of the HTTP specification to generate the SAP logon ticket from AS-Java in order to be used by
AS-ABAP - in manner that is invisible to the user. An overview of the solution is illustrated in Figure 3.
Figure 3. SSO to AS-ABAP and AS-Java without visible redirection and without using the GSO.
- The user requests an AS-ABAP resource via WebSEAL. Authentication credentials are provided to WebSEAL.
- After successful WebSEAL authentication, WebSEAL redirects the browser using a page that both contains a link to a hidden image on AS-Java and
a redirect to the requested resource. By containing a link to AS-Java, the browser obtains the SAP logon ticket.
- The browser automatically requests the hidden image
- WebSEAL receives the request for the AS-Java image resource and sends the username of the authenticated user in the form of an HTTP header called 'iv-user'.
- AS-Java receives the request and verifies the existence of the user in the SAP user registry.
- After successful verification, the user is supplied with the SAP logon ticket and the requested (hidden) image.
- At this point, the browser automatically follows the redirect to the AS-ABAP application. This time, the request is not redirected by WebSEAL because the user
is already authenticated.
- The request for the AS-ABAP resource is passed to the AS-ABAP server. The request contains the SAP logon ticket generated by the AS-Java.
- The SAP logon ticket is used to authenticate the user.
- After successful authentication, the user is supplied with the requested content.
The remaining section of this article describe how to configure the software components in order to support the solution outlined above.
Configuring Tivoli Access Manager WebSEAL
This section provides the steps required to configure Tivoli Access Manager WebSEAL.
Configuring redirection on authentication
Perform the following actions to configure WebSEAL to instruct the browser to retrieve the SAP logon ticket before redirecting to the
requested resource after successful authentication:
 | |
- Open the WebSEAL configuration file. For example, with a default installation of WebSEAL, the configuration file is located at
WebSEAL_root/etc/webseald-default.conf.
- Within the
[acnt-mgt] stanza, locate the login-redirect-page parameter.
- Set the
login-redirect-page parameter to /redirect.html.
- Within the
[enable-redirects] stanza, enable the appropriate authentication mechanism. For example, when using forms
authentication, ensure the redirect parameter is set to forms-auth.
- Within the
[server] stanza, locate the process-root-requests parameter.
- Set the
process-root-requests parameter to either filter or always.
- If the
process-root-requests parameter is set to always, ensure an entry is added in the
process-root-filter stanza. For example, root = /redirect.html.
- Restart WebSEAL to affect the above changes.
In summary, the configuration file should contain the settings as per Listing 1.
Listing 1. WebSEAL Configuration settings.
[acnt-mgt]
...
login-redirect-page = /redirect.html
[enable-redirects]
redirect = forms-auth
[server]
...
process-root-requests = filter
[process-root-filter]
root = /redirect.html
|
Modifying the WebSEAL login page
Perform the following actions to modify the WebSEAL login page to capture the requested URL:
- Locate the WebSEAL login page template in the WebSEAL lib directory. For example, with a default installation of
WebSEAL, the lib directory is located at: WebSEAL_root/www-default/lib/html/language (where language is "C" for English).
- Modify the file to contain the JavaScript supplied in Listing 2.
Listing 2. Redirection page.
<script>
document.cookie = 'RedirectURL=%HTTP_BASE%%URL%';
</script>
|
Creating the redirection page
Perform the following actions to create the redirection page returned by WebSEAL after authentication:
- Create a new file called
redirect.html in the WebSEAL "docs" directory. For example, with a default installation of
WebSEAL, the "docs" directory is located at: WebSEAL_root/www-default/docs.
- Modify the file to contain the HTML supplied in Listing 3.
|
Cookie Functions (cookieFunctions.js)
For the sake of brevity, the JavaScript for "cookieFunctions.js" has not been included in this article. These functions provide the code for
getting/setting/deleting cookies - perform an internet search using your favourite search engine to locate the functions Here's a
link to assist.
|
|
Listing 3. Redirection page.
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
<title></title>
</head>
<script language="javascript" src="cookieFunctions.js">
</script>
<script language="javascript">
function redirect()
{
var default_redirectURL = "/index.html";
var redirectURL = getCookie("RedirectURL");
deleteCookie("RedirectURL");
document.location = (redirectURL != null && redirectURL != '' ?
redirectURL : default_referrer);
}
</script>
<frameset rows="0%" onLoad=redirect()>
<frame name="a" src="/sapasjava/SSOTicket/index.html">
</frameset>
</html>
|
Creating the WebSEAL junctions
WebSEAL requires a junction to be created for each of the Application Servers, i.e. a junction for AS-Java and a junction for AS-ABAP.
The section below, Configuring SSO to the SSO ticket generating application, provides a link to an integration guide
specifying the details on how to create the junction to AS-Java. When creating the junction, ensure the junction name matches the value used in the
redirect.html file. Using the sample listing provided above, the junction would be called /sapasjava.
The junction to AS-ABAP does not require any particular settings, apart from those required to connect to the web interface. The WebSEAL
configuration options (configured using webseald-instance.conf) will be dependent on the application being accessed
on the AS-ABAP server, and a discussion on this topic is outside the scope of the article. The example provided in the Testing the
Configuration assumes the junction is called /sapasabap.
Configuring SAP NetWeaver Application Server Java
This section provides the information required to configure AS-Java to accept the HTTP header passed from WebSEAL containing the authenticated user
in order to generate the SAP logon ticket.
Deploying a SSO ticket generating application
For AS-JAVA to generate the SAP logon ticket, an authenticated user must access a protected application deployed on AS-Java. This can be done using
an existing protected application by referencing one of its images. The application requires allowing the everyone role access to the referenced
image. Alternatively, a simple application has been provided with this article, SSOTicket.ear (supplied in SSOTicket.zip), that is suitable for use with the redirection page as
created earlier in the article. The simple application contains one image, named 1x1.gif, that is accessed by the redirection page. Access
to this image is restricted to the everyone group. This requires the user to be authenticated by AS-Java, allowing us to make use of the
SAP logon ticket generated on successful authentication (as configured below).
Perform the following steps in the SAP Visual Administrator to deploy the simple application:
- Expand
server - Deploy.
- Click the Deploy & Start button.
- In the File edit control, enter the full location and name of the simple application, SSOTicket.ear
- Click OK.
- If you receive a warning message about the deploy location, click OK.
- In the Deploy Dialog, click OK. The simple application will now be deployed to AS-Java.
- To confirm successful deployment, change the Deployed Components view to Application.
- Within the list of deployed components, locate the entry for sap.com/SSOTicketEar. The application should be started. If not, click the
Start Application button.
Once the application is deployed, attempt to access the image using a browser. The image is accessed via the URL:
http://as-java:port/SSOTicket/1x1.gif. You should receive a prompt for authentication and a blank page result after successful
authentication.
Configuring SSO to the SSO ticket generating application
IBM provides an integration package containing information on how to
configure SSO between WebSEAL and AS-Java. Follow each of the steps outlined in the integration guide to configure SSO between WebSEAL and the ticket
generating application deployed in the previous step.
To summarise the integration procedure:
- WebSEAL is configured with a junction to AS-Java. The junction supplies the TAM authenticated user-id to AS-Java in an HTTP header.
- AS-Java is configured with a J2EE LoginModule to read the HTTP header and validates the user-id using the SAP User Management Engine (UME).
- After successful validation, the browser is supplied the MYSAPSSO2 cookie, i.e. the SAP logon ticket.
Examine the list of cookies to ensure the MYSAPSSO2 cookie is supplied when testing the integration.
Configuring SAP NetWeaver Application Server ABAP
This section provides information on how to configure AS-ABAP to accept SAP logon tickets generated by AS-Java.
Configuring trust with AS-Java
AS-ABAP must be configured to trust the SAP logon ticket generated by AS-Java. This is done using the STRUSTSSO2 transaction by loading the AS-Java
server certificate into the certificate list and ACL of the AS-ABAP. Refer to the
SAP Library for detailed information
on how to configure the trust relationship.
Testing the Configuration
To test for a successful configuration, simply access an AS-ABAP application via WebSEAL. After authenticating to WebSEAL, your browser should
display the AS-ABAP application without requiring further authentication.
For example, open your browser and navigate to the SAP GUI for HTML (webgui) application: http://webseal_fqdn/sapasabap/sap/bc/gui/sap/its/webgui/!.
Download | Description | Name | Size | Download method |
|---|
| Simple AS-Java Application | SSOTicket.zip | 3KB | HTTP |
|---|
Resources
About the author | 
| | Peter Tuton is a Software Engineer in the Tivoli Security Integration Factory Team based on the Gold Coast, Australia. In this role, Peter is the Technical Lead for the team developing integration solutions for Tivoli Access Manager and Tivoli Federated Identity Manager. Peter has been involved in the certification of a number of IBM integration solutions with leading software companies, including Siebel, PeopleSoft and SAP. |
Rate this page
| 
