Show TOC

Header VariablesLocate this document in the navigation structure

Use

SAP NetWeaver Application Server (AS) Java supports the use of header variables for authentication and Single Sign-On (SSO). With header variables, you can use a third-party Web access management (WAM) product to authenticate your users. The WAM product returns an authenticated user ID as part of the HTTP header. Users only have to authenticate once against the WAM product and can then access applications on the AS Java with SSO.

The figure below presents an overview of the process flow for header variable authentication.

Figure 1: Process Flow for Authentication with Header Variables

Authentication with a WAM product works as follows:

  1. The WAM product authenticates the user and returns an authenticated user ID to the AS Java as part of the HTTP header.

  2. The AS Java compares this user ID against those available in the data sources of the user management engine (UME).

  3. The AS Java authenticates the user upon finding a match.

The AS Java provides the HeaderVariableLoginModule login module that reads a user ID from the HTTP header variable and then uses this user ID to authenticate the user. Use this login module if you are already using third-party WAM product to protect other resources in your company, or if you use authentication mechanisms that are not directly used by the AS Java, such as token cards or biometrics.

Prerequisites

  • To use a third-party product with the header variable login module for authentication, you must use an external intermediary server for access to the AS Java. All requests must pass through the intermediary server.

  • The user ID that the third-party product returns in the HTTP header must exist in the UME data sources.

Security Considerations

Attackers can impersonate a user by sending a request with a user ID in the appropriate header variable to the AS Java. To prevent such attacks, do the following:

  • Using appropriate measures, make sure that the HTTP and HTTPS ports of the AS Java cannot be directly accessed by client Web browsers, for example by using firewalls. Users should only access the AS Java through its intermediary server. This prevents attackers from bypassing the intermediary server and impersonating authenticated users.

  • If it is not possible to block the HTTP and HTTPS ports of the AS Java, you must configure Secure Sockets Layer (SSL) with mutual authentication between the intermediary server and the AS Java. This way, the AS Java can trust that user information contained in the header variable, because it comes from a trusted server.

    To set up SSL with mutual authentication between the intermediary server and the AS Java, add the certificate of the intermediary server to the list of trusted root certificates in the AS Java. Then configure the AS Java to accept only incoming requests that are signed with the certificate of the intermediary server.

    For more information about configuring SSL with an intermediary server on the basis of an example using SAP Web Dispatcher, see Using SSL With an Intermediary Server .

If you deploy a portal on your AS Java, you must consider how header variables can hinder log off. By default, portal users are redirected to the default logon screen after they log off. If the portal uses a WAM product to authenticate users, the portal logoff cannot delete the session identifiers created by the external tool. Users are automatically logged on again. It is impossible for users to log off the portal. To prevent portal users from being logged on again automatically, redirect users to a screen other than the default logon screen at logoff.

For more information, see the portal documentation.

Configuration

The exact steps for setting up authentication with header variables depends on the product you use. In all cases, you must adjust the login module stacks or templates of the applications to use header variable authentication.

For more information, see Using Header Variables .