Sap Redirect Url Is Null

Symptom

Upon logging into the Enterprise Portal you are encountering a Portal runtime error exception across specific instances.
When analyzing the default trace file you highlight several error exceptions as pointing to URL Caching:

NavigationService.redirect: recieved exception when calling to redirectors with URL (null result is returned from redirect) [EXCEPTION] javax.naming.NamingException: The old URL is null at com.sap.portal.ivs.global.navigation.connector.NavigationRedirector.redirect

Environment

Product

This causes null to be in the URL, even if you have no options. So I figured, because caching is off by default, this should be appending a timestamp. But it actually appends null. So I thought I'll set it to be cachable, which then forced me to put null which didn't fix the problem. I assume that's the issue you've just fixed?

SAP NetWeaver all versions

The default value of this redirections is null. SAP has a list with all the default pages that our customers can use, in case you don't have any particular page to set for this. You can check all these URLs for each DC in this KBA: Default Redirect URLs for Single Sign On. To change it, you need to have access to Provisioning. Beginning with release 7.2 the SAP Web Dispatcher is now able to rewrite URL (as Apache) and not only to redirect URLs. It means that it is now possible to use the technique number 3 with a SAP web dispatcher. No more need to cascade an Apache reverse proxy (for URL rewriting) and a SAP Web Dispatcher (for load balancing). A redirect URI, or reply URL, is the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. The authorization server sends the code or token to the redirect URI, so it's important you register the correct location as part of the app registration.

Keywords

Enterprise Portal 7.0, EP 7.0, Enterprise Portal 7.01, EP 7.01, Enterprise Portal 7.02, EP 7.02, Enterprise Portal 7.1, EP 7.1, Enterprise Portal 7.2, EP 7.2, Enterprise Portal 7.30, EP 7.30, Enterprise Portal 7.31, EP 7.31, Enterprise Portal 7.40, EP 7.4, FPN, Cache, clearing, old, URL, retained, null, NavigationService, redirect, recieved, exception, redirectors, clear, Navigation, FPN, , KBA , EP-PIN-NAV , Navigation , EP-PIN-FPN , Federated Portal Network , Problem

About this page

This is a preview of a SAP Knowledge Base Article. Click more to access the full version on SAP ONE Support launchpad (Login required).

Search for additional results

Visit SAP Support Portal's SAP Notes and KBA Search.

in conjunction with SAP NetWeaver Application Server Java

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.

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.

Creating the redirection page

Perform the following actions to create the redirection page returned by WebSEAL after authentication:

Url Redirect Iis

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.

Listing 3. Redirection page.

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 theredirect.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 accessedon the AS-ABAP server, and a discussion on this topic is outside the scope of the article. The example provided in the Testing theConfiguration 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 usingan 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.