Securing Header Authentication

Securing Header Authentication

© 2006 SAP AG The SAP Developer Network: http://sdn.sap.com 1

Applies To:

SAP NetWeaver WAS (Java) 04 and 04s

Summary

This article describes an easy to implement approach to secure Header Authentication and Integrated Windows Authentication. As an additional benefit, this approach allows a considerable performance improvement by avoiding dispensable http round-trips caused by the native authentication mechanism in the standard approach. A login module is available for download. You can use the IPHeaderLoginModule attached to this article in order to control the IP addresses for which Header Variable Authentication is allowed.

By: Dr. Jörg Wulftange

Company: Platinion GmbH

Date: 3. February 2006

Table of Contents

Applies To:........................................................................................................................................1

Summary ..........................................................................................................................................1

Table of Contents .............................................................................................................................1

Introduction.......................................................................................................................................2

Securing Header Variable Authentication ........................................................................................2

Preface: Security Threats with Header Variable Authentication...................................................2

Practical Guide: Securing Header Authentication ........................................................................4

Technical Review: The function of the IPHeaderLoginModule.....................................................5

Security consideration ..................................................................................................................8

Tuning your Header Variable Authentication ...................................................................................8

Motivation......................................................................................................................................8

Installation.....................................................................................................................................8

Author Bio.........................................................................................................................................9

Disclaimer & Liability Notice .............................................................................................................9

https://sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/business_packages/a1-8-4/IPHeaderLoginModuleLibrary.zip




Introduction

It is a convenient approach to delegate the authentication of users to SAP external products. These products filter the HTTP request, and set an HTTP header variable with the user name, if the user has provided sufficient means to authenticate (e.g. user id and password). The header variable is parsed by a J2EE login module for authenticating the user with the SAP J2EE (see http://java.sun.com/products/jaas/ for more information on login modules). One popular use is Integrated Windows (or Kerberos) Authentication, since it is available without additional implementation effort if you use Microsoft’s ADS as user repository. Other examples are CA’s Siteminder, Oracle’s Oblix, RSA’s ClearTrust or Entrust’s GetAccess to name a few.

This article describes in the first part an easy to install and easy to maintain approach to secure this authentication approach, avoiding configuration of mutual SSL authentication or an additional firewall setup between the authenticating web server and the J2EE.

Additional (http) round-trips and the ensuing loss of performance is the price to be paid in many cases when authenticating with header variables. In the second part, we describe how to avoid these extra round trips using a simple redirect approach. Thus we are able to considerably improve the performance of, by way of example, the Enterprise Portal communication, when using Integrated Windows Authentication.

Taking the perspective of the SAP J2EE, Integrated Windows Authentication (and Kerberos not relying on the J2EE Kerberos Login Module) employs the same technique as other methods using HTTP Header Variable Authentication. Therefore, Integrated Windows Authentication can be considered as a special case of Header Variable Authentication. When discussing Header Variable Authentication below, Integrated Windows Authentication is implied as a special case.

Securing Header Variable Authentication

Preface: Security Threats with Header Variable Authentication

As mentioned in the introduction, Header Variable Authentication delegates the actual authentication of the user to the non-SAP product. If the authentication succeeds, this external provider adds an http header variable containing the login name of the user to the HTTP request. Therefore, the protection is at best as strong as that of the authenticating service – which might actual be very strong depending on the chosen authentication product. However, if no measures are taken to protect the J2EE from unauthenticated requests containing the same header variable, it is very easy for an attacker to get authenticated as any user without requiring advanced technical knowledge or even any secret information, such as passwords.

Let’s consider the following example: An IIS authenticates the user via Kerberos Authentication in MYDOMAIN, and then forwards the request with the IISProxy module to the J2EE. Say, the J2EE with a Portal has been configured for Integrated Windows Authentication, listening on http://j2eehost:50000/irj. Now, using any tool for generating raw HTTP requests, I can easily let the engine issue a MYSAPSSO2 Cookie for any user without knowing private credentials of this user, like a password (see Figure 1). Thus, I get full control over the J2EE, the Portal, and – in most cases even worse – all backend applications that trust the J2EE, like HR, FI etc.

http://java.sun.com/products/jaas/

http://j2eehost:50000/irj


© 2006 SAP AG The SAP Developer Network: http://sdn.sap.com

Figure 1: Authentication attack against an Enterprise Portal

Consequentially, you need to ensure that the incoming request has really passed through the authenticating software. It is the responsibility of the authenticating software to remove a header variable added by some attacker to the http request (the IISProxy removes the header variable REMOTE_USER used for Integrated Windows Authentication if contained in the incoming request).

Therefore, SAP recommends securing your J2EE using mutual SSL authentication (see http://help.sap.com/saphelp_nw04/helpdata/en/d0/a3d940c2653126e10000000a1550b0/frameset.htm). This ensures a very high level of security.

On the other hand, this approach also implies some inconveniences which can be avoided by using a login module like that provided with this article. It verifies the IP address of the incoming HTTP request against a list of trusted IP addresses. If the incoming request is sent from a trusted IP address, it is granted that the request has been passed via the authenticating software. This approach has the following advantages:

No necessity to do configuration with different SSL Tools (Visual Administrator, sapgenpse) No necessity to care for certificate maintenance (expiry control, etc.) Easy to scale with multiple IIS (e.g. for high availability) Easy configuration for co requisite configuration of header based authentication and password based

authentication Considerable amount of security Good performance

3

http://help.sap.com/saphelp_nw04/helpdata/en/d0/a3d940c2653126e10000000a1550b0/frameset.htm





Practical Guide: Securing Header Authentication

You can use the IPHeaderLoginModule attached to this article in order to control the IP addresses for which Header Variable Authentication is allowed. This login module extends the SAP provided HeaderVariableLoginModule. Therefore, it uses standard SAP functionality besides the check discussed in this article.

For using the example code, follow the steps indicated below:

1. Deploy the attached sda file with the SDM (see http://help.sap.com/saphelp_nw04/helpdata/en/92/fb673ba8ecf22fe10000000a11402f/frameset.htm)

2. Configure your system for authentication with header variable (see http://help.sap.com/saphelp_nw04/helpdata/en/d0/a3d940c2653126e10000000a1550b0/frameset.htm)

3. Add the new Login Module to the class loader with the name: library:de.platinion~IPHeaderLoginModuleLibrary (in the Visual Administrator -> Server -> Services -> Security Provider -> Properties, set LoginModuleClassLoaders to the value library:de.platinion~IPHeaderLoginModuleLibrary; you can look up the name in the Visual Administrator -> Server -> Services -> ClassLoader Viewer). The library is loaded after the next restart of the J2EE.

4. Register the login module with the class name de.platinion.security.IPHeaderLoginModule and any name, e.g. IPHeaderLoginModule (see http://help.sap.com/saphelp_nw04/helpdata/en/95/fcd340fa1a732ae10000000a155106/frameset.htm)

5. In the Visual Administrator -> Server -> Services -> Security Provider, replace the HeaderVariableLoginModule from the login module stack ticket with the new IPHeaderLoginModule. Add to the properties inherited from the HeaderVariableLoginModule the option ip=<comma separated list of trusted IP addresses>

Figure 2: Configuration of the IPHeaderLoginModule

4



http://help.sap.com/saphelp_nw04/helpdata/en/92/fb673ba8ecf22fe10000000a11402f/frameset.htm



http://help.sap.com/saphelp_nw04/helpdata/en/95/fcd340fa1a732ae10000000a155106/frameset.htm



With this configuration in place, users can authenticate only, if their request is passed via one of the specified IP addresses from the option ip.

Referring to our example above, we would specify the IP address of the IIS in the IPHeaderLoginModule property (e.g., ip=127.0.0.1 beside the properties we have defined for the HeaderVariableLoginModule, see Figure 2).

In case the Header Authentication fails after the configuration, you can increase the trace severity on the server for the locations com.sap.security.core.server.jaas and com.sap.engine.services.security to All for problem analysis. Look for Warnings, Errors and Fatals in locations com.sap.security.core.server.jaas and com.sap.engine.services.security. The first might indicate a problem with the IP address recognition; the latter typically indicates a problem with the initialization of one of the login modules (probably a class loading problem due to a typo).

Figure 3: Configuration of tracing location severity

Technical Review: The function of the IPHeaderLoginModule

The IPHeaderLoginModule extends the SAP HeaderVariableLoginModule. Basically, it overrides the login() method from parent class as follows:

public boolean login() throws LoginException {

//first we check the ip address

HttpGetterCallback hgc = new HttpGetterCallback();

Exception onthewayexc = null;

5



ExceptionLogger.LOCATION.debugT("Entering login of IPHeaderLoginModule.");

hgc.setType(HttpGetterCallback.CLIENT_IP);

try {

_callback_handler.handle(new Callback[] { hgc });

} catch (IOException e) {

onthewayexc = e;

} catch (UnsupportedCallbackException e) {

onthewayexc = e;

}

if (onthewayexc != null) {

ExceptionLogger.log(Severity.WARNING, onthewayexc);

throw new LoginException(onthewayexc.toString());

}

_ip = (String) hgc.getValue();

ExceptionLogger.LOCATION.debugT(

"login",

"request ip has value {0}",

new Object[] { _ip });

if (_trusted_ips.indexOf(_ip)==-1){

ExceptionLogger.LOCATION.warningT ("login", "IPHeaderLoginModule did not succeed. IP {0} is not part of allowed IP addresses.", new Object[] { _ip });

throw new LoginException ("IP " + _ip + " is not contained in the list of trusted IP addresses.");

}

//here we trust the ip address

ExceptionLogger.LOCATION.debugT("Exiting login of IPHeaderLoginModule with trusted IP. Calling super class HeaderVariableLoginModule.");

return super.login();

}

All other methods are inherited from the parent class, beside a small change in the initialize() method.

Therefore, a login with a set header variable is successful, only if the request has been passed via a trusted IP address (proxy). Performing the same request as in the first chapter leads to a denial of authentication by



the J2EE, and thus to a log on failure (see Figure 4). Access to the Enterprise Portal is denied to the potential attacker, and his IP address is traced.

Figure 4: Fended off attack against a Portal

The default trace actually traces the illicit request (with tracing severity of location jaas increased to Warning, see Figure 5):

Figure 5: Trace Message of a potential attack

7



Security consideration

As already mentioned above, preventing direct access from the client (browser) to the J2EE via enforcing mutual SSL authentication gives a very high level of security – plus the additional benefit of encrypted communication between the Web Server (e.g., IIS) and the J2EE.

On the other hand side, the SSL handshake generates some overhead as a drawback. This is especially dispensable in environments, where the communication between the IIS and the J2EE is trusted (e.g. since the IIS and the J2EE are on the same host, or they are in a trusted network).

Using the Login Module from above, you can save this overhead. Although not as secure as mutual SSL authentication, the IP verification provides a considerable amount of authenticity considering the fact that straight forward IP spoofing attacks would not lead to successfully retrieving the authentication cookie. See also http://www.ietf.org/rfc/rfc791.txt, http://www.ietf.org/rfc/rfc793.txt and http://www.bsi.bund.de/english/gshb/manual/t/t05078.html.

Tuning your Header Variable Authentication

Motivation

When authenticating users via an http header variable you often get a considerable overhead of http round-trips caused by the iteration of external authentication checks. E.g., if you use Integrated Windows Authentication, each new tcp connection needs to be authenticated against the windows network, which leads to additional http round-trips caused by the repeatedly negotiated handshakes (this is noticeable especially since the network traffic of one browser is not routed via one tcp connection, but the Internet Explorer opens several tcp connections in parallel when downloading mimes and scripts). You can reduce the number of additional HTTP round-trips by adjusting the http keep-alive settings between the IIS, the IISProxy and the J2EE. But there is still an overhead of ca 30% of the http requests (with small body content), leading to longer response times for the user and higher network traffic – which is especially painful in distributed landscapes due to the latency.

You can avoid these extra round-trips completely by redirecting to the J2EE port (or a non-authenticating second proxy port) after the authentication of the user with the J2EE. The direct connection to the J2EE port is made possible by the IPHeaderLoginModule discussed in the first part. It allows us keeping the J2EE Port open to the client, and thus directly connecting to the J2EE.

Installation

Via a simple jsp we enforce an authentication on the default login module stack “ticket”, and then redirect the request to the default page of the Portal. In order to do so, we need to save a text file with the name ntlm.jsp in all j2ee server directories under /irj/root/ containing the code from below

<%@ page session = "true" %>

<%@ page import = "com.sap.security.api.*" %>

<html>

<head>

<title>Redirecting to Portal...</title>

<%

http://www.ietf.org/rfc/rfc791.txt

http://www.ietf.org/rfc/rfc793.txt

http://www.bsi.bund.de/english/gshb/manual/t/t05078.html



IUser user =

UMFactory.getAuthenticator().getLoggedInUser(request, response);

if (null == user) {

UMFactory.getAuthenticator().forceLoggedInUser(request, response);

}

%>

</head>

<body onload="location.replace('http://<j2ee server>:<j2ee port>/irj/portal' + document.location.search)"></body>

</html>

We need to replace the line 'http://<j2ee server>:<j2ee port>/irj/portal' with the URL of our own server – and that’s it. When calling the Portal now via http://<IIS>/irj/ntlm.jsp, an Integrated Windows Authentication is enforced, an authentication ticket is issued (wrapped in a MYSAPSSO2 Cookie) and subsequent requests are directed to the J2EE Server bypassing the IIS.

Code disclaimer information

This document contains programming examples.

You are granted a nonexclusive copyright license to use all programming code examples from which you can generate similar function tailored to your own specific needs. All sample code is provided for illustrative purposes only. These examples have not been thoroughly tested under all conditions. Therefore guarantee or imply reliability, serviceability, or function of these programs cannot be guarantied. All programs contained herein are provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchantability and fitness for a particular purpose are expressly disclaimed.

Author Bio

Dr. Jörg Wulftange is working as an IT Architect with Platinion — a wholly owned IT-consulting and e-business subsidiary of The Boston Consulting Group that provides end-to-end solutions to clients. Before joining Platinion, Jörg has worked for several years as a developer with SAP AG.

Disclaimer & Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk.

9



SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.

Securing Header Authentication

Documents

Transcript of Securing Header Authentication