Sap Redirect Url Is Null

/ Comments off

Redirect 301 is a good way helping you to move and entire website from the old domain to a new domain, and it takes 1 to 2 weeks for google search engine to replace all the old URLs. Issue: You are updating your context and web files as instructed here: JNDI Services on Apache Tomcat.You have also ensured that the JDBC driver used by your JNDI connection is placed in the lib directory of your application server (ex: apache-tomcat/lib).and you restart the server. Unfortunately, attempts to connect to your new JNDI resource result in the following error: Cannot create. You have logged off: Copyright © SAP AG. All Rights Reserved. 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 these redirect URL. The redirected URL can point to the same domain or to a different domain. Other than 302 status code there are a number of other codes which can be used. Please check out our tutorials on basics of URL redirection and URL redirect in Java Servlet. Using RedirectView. RedirectView is the suggested way to perform URL redirection.

  1. Redirect Url In Html
  2. Url Redirect Iis

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.

How to download utorrent in windows 10 in hindi. 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.
  1. The user requests an AS-ABAP resource via WebSEAL. Authentication credentials are provided to WebSEAL, if required.
  2. After successful WebSEAL authentication, WebSEAL retrieves the user's AS-ABAP credentials from the GSO Lockbox.
  3. The AS-ABAP credentials are sent to AS-ABAP using Basic Authentication.
  4. AS-ABAP authenticates the user against the SAP user registry (e.g. SAP DB) using the credentials sent via the BA header.
  5. After successful AS-ABAP authentication, the user is supplied with the requested AS-ABAP content, along with the SAP logon ticket.
  6. 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.
  1. The user requests a AS-ABAP resource via WebSEAL. Authentication credentials are provided to WebSEAL.
  2. After successful WebSEAL authentication, WebSEAL redirects the browser to an AS-Java application in order to obtain the SAP logon ticket.
  3. The browser automatically follows the redirect from WebSEAL.
  4. 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'.
  5. AS-Java receives the request and verifies the existence of the user in the SAP user registry.
  6. After successful verification, the user is supplied with the SAP logon ticket and content from the AS-Java application.
  7. 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.
  8. 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.
  9. The SAP logon ticket is used to authenticate the user.
  10. 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.
  1. The user requests an AS-ABAP resource via WebSEAL. Authentication credentials are provided to WebSEAL.
  2. 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.
  3. The browser automatically requests the hidden image
  4. 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'.
  5. AS-Java receives the request and verifies the existence of the user in the SAP user registry.
  6. After successful verification, the user is supplied with the SAP logon ticket and the requested (hidden) image.
  7. 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.
  8. 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.
  9. The SAP logon ticket is used to authenticate the user.
  10. After successful authentication, the user is supplied with the requested content.
UrlGoogle redirect url

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:

  1. 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.
  2. Within the [acnt-mgt] stanza, locate the login-redirect-page parameter.
  3. Set the login-redirect-page parameter to /redirect.html.
  4. 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.
  5. Within the [server] stanza, locate the process-root-requests parameter.
  6. Set the process-root-requests parameter to either filter or always.
  7. 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.
  8. 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:

  1. 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).
  2. 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:

  1. 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.
  2. 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:

  1. Expand server - Deploy.
  2. Click the Deploy & Start button.
  3. In the File edit control, enter the full location and name of the simple application, SSOTicket.ear
  4. Click OK.
  5. If you receive a warning message about the deploy location, click OK.
  6. In the Deploy Dialog, click OK. The simple application will now be deployed to AS-Java.
  7. To confirm successful deployment, change the Deployed Components view to Application.
  8. 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: Kingdom come deliverance console command for bow reticle.

  • 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.
Record

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

Downloadable resources

  • Simple AS-Java Application (SSOTicket.zip | 3KB)

Related topics

Redirect Url In Html

  • IBM Tivoli Access Manager SAP Netweaver AS Java Integration Adapter.
  • For a complete list of integration solutions available for Tivoli Access Manager for e-business, visit the IBM Website.
  • For information on using SAP logon tickets for Single Sign-On, visit the SAP Library.
  • For an overview of Tivoli Access Manager for e-business, visit the IBM website.
  • For additional information on configuring SAP systems, visit the SAP Service Website.

To Configure the ume.logoff.redirect.url Parameterfor SAP Enterprise Portal 7.0

This is one of the post-installation tasks required when Agent for SAP Enterprise Portal 7.0/Web Application Server 7.0 hasbeen installed on SAP Enterprise Portal 7.0.

Url Redirect Iis

  1. Start the J2EE Engine configuration tool.

    The followingexample provides the path to the configuration tool on UNIX systems:

    SID

    represents the SAP system ID.

    instanceName

    represents the SAP Enterprise Portal 7.0 instance.

    For a graphical representation of the configuration tool as describedin the steps that follow in this task, see Figure 4–11.

  2. Click the pencil icon to switch to the configuration editor mode.

  3. Click the pencil and glasses icon.

  4. Select cluster_data -> server -> cfg -> services.

    The UME service property sheet appears.

  5. Double click the following property sheet: com.sap.security.core.ume.service

  6. Add the following custom value to the property named ume.logoff.redirect.uri:

    http://AMServices-host:AMServices-port/amserver/UI/Login?arg=newsession

    AMServices-host

    represents the fully qualified host name of the server where Access Manager Servicesare installed.

    AMServices-port

    represents the port number of the server where Access Manager Servicesare installed.

    Figure 4–11 SAP Config Tool: Configuring the ume.logoff.redirect.url Parameter