Skip to Content
Author's profile photo Tobias Lejczyk

Configure Network Edge Authentication

With ABAP 7.51, a new authentication scenario was announced: Network Edge Authentication.

You can read about it here.

This is a great new feature for securing http-based access to your systems. This blog will guide you through the implementation, using x509 certificates as token type, in the different systems.


The documentation regarding network edge authentication can be found here:

SSO Backend System

Within the SSO Backend System you need two software packages:


The SSOAUTHLIB provides the authentication and certificate fetching mechansim, while the SECURELOGINSERVER provides the certificate signing functionality.

Create an empty authentication stack in the NWA, called for example “none”.


Go to https://<host>:<port>/slac –> Profile Management –> Authentication Profiles –> Create

Choose a name for the profile. This name is later referenced in the NEA endpoint configuration.
The client type has to be a client, the user authentication does not matter (the user authentication is done at a nea-endpoint, not the endpoint created here). Select for example “Secure Login Client Profile” and select the empty logon stack created above.

The certificate configuration can be kept at the default. The DN is always “CN=<Username>”. Just make sure, that the selected CA is the User CA.

The enrollment configuration can also be ignored and the configuration can be finished here.

Configuring NEA Endpoint

Go to https://<host>:<port>/nwa –> Configuration –> Security –> Authentication and Single Sign-On

Filter the overview for the name “nea” and the type “Web”. The relevant Policy Configuration is “*nea_v1_authenticate”:

If you don’t specify a template, the default stack (usually “ticket”) is used. You can also configure a NEA specific stack (as in the screenshot) or a completely individual stack.

Within the properties of the policy, set the property “x509_sls_profile_name” to the name of the SecureLoginServer Authentication Profile created in the previous step.

Grant NEA permission to access the SecureLoginServer keystore view

The NEA application needs permissions to access the SecureLoginServer keystore view.

Go to NWA -> Configuration -> Security -> Certificates and Keys -> Security -> Permissions per Domain

Filter for the nea application and add the permissions READ_ENTRY for the SubCA that issues your certificates in the SecureLoginServer keystore view

This concludes the configuration in the SSO System.


In the Webdispatcher, there are two types of systems in a NEA-configuration.

  1. One Auth-System
    The SSO System, that authenticates the user and issues the certificate
  2. All other backend systems
    These systems reference the Auth-System in their configuration. So requests only reach these systems, if they are already authenticated with the Auth-System.

All these systems are configured by subparameters of the wdisp/system_<x> parameters. So the systems themselves are connected in the established manner.

Important: Routing in a NEA scenario has to happen via “SRCVHOST” subparameter (and optionally SRCURL subparameter). See note 2432861.

Configuring the Auth-System

To configure the Auth-System, the subparameter “AUTH_SERVICE” is pointed to the NEA enpoint (usually https://<host>:<port>/nea/v1/authenticate). Any not authenticated is redirected to this service. The host/port is the host and port of the SSO system on the Webdispatcher.

In addition, the DOMAIN_RELAX cookie should be set at least to 1 to ensure, that the Webdispatcher Session Cookie is valid for other systems than the SSO system.

Configuring the other backend systems

All other systems have two subparameters that are required/recommended:

    This references the SID of the Auth-System configured before
  • [Optional, but recommended] MANAGED_SESSION_COOKIES=<RegEx>
    This parameter specifies, which cookies should be managed by the WebDispatcher and not returned to the client. Recommended settings:

    • Java
    • ABAP


The Webdispatcher should have

  • Signed HTTPS Server certificate
  • Signed HTTPS Client certificate!

The signed client certificate is necessary, because the Webdispatcher needs to authenticate at the backend to forward the client identity.

The Webdispatcher needs to talk HTTPS to the backend systems always. To enable this, set the parameter

wdisp/ssl_encrypt = 2


In the backends, client certificate based authentication needs to be enabled.

This means, that all backend systems have to have HTTPS enabled.

The backends need to trust the webdispatcher to forward client certificates. To enable this, you need to

  • Trust the client certificate of the webdispatcher
    To do this, import the root CA of the webdispatcher client certificate into the HTTPS certificate store (probably in transaction STRUST or NWA)
  • Trust the webdispatcher to forward client certificates via HTTP Headers
    This is done either by entering subject and issuer of the client certificate into either the old parameters
    or the new parameter
    icm/trusted_reverse_proxy_0 = SUBJECT=”<Subject>”, ISSUER=”<Issuer>”
    see note 2052899

With these settings the HTTP Headers containing the user certificate are evaluated.

Mapping the user certificate to the user is done in the usual way.
In an ABAP stack it is recommended to use transaction certrule and create the needed rule.
In a Java Stack, the rule is created in the login module.

The certificate from SLS is always issued to:
Subject: CN=<Username>
Issuer: <DN of the SubCA selected in the SLS>

If you want to double check the certificate that is coming in, use the icm/HTTP/logging parameter to create a log containing the request headers.


Troubleshooting can be done with the following tools:

Troubleshooting Wizard – https://<host>:<port>/tshw
There you should create a new incident with the trace location

In the webdispatcher you can use the webdispatcher trace level or, if necessary, the icm-Request-logging (

In the backend you can use the icm trace level or the icm-Request-logging (see Webdispatcher)

In addition, if there are any cryptography errors, you may find some information in the common crypto lib traces (see note 1996839 and 2338952).



All the best for your configuration.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Achim Braemer
      Achim Braemer

      Great article, thank you!

      Let me make add one point for clarification: The SAP Web Dispatcher and SAP Single Sign-On product need to be a fairly current version in order to provide this services. But the backend systems to which the SSO service is provided can be any release starting with 7.0, both ABAP and Java systems. So Network Edge Authentication can be used to secure just about any existing SAP system landscape.

      Regards, Achim

      Author's profile photo Tobias Lejczyk
      Tobias Lejczyk
      Blog Post Author

      Hi Achim,

      thank you very much for that very important clarification :).

      Regards, Tobias