Skip to Content

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.

Documentation

The documentation regarding network edge authentication can be found here:

SSO Backend System

Within the SSO Backend System you need two software packages:

  • SSOAUTHLIB
  • SECURELOGINSERVER

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”.

Configuring the SECURELOGINSERVER

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 “sap.com/sso~nea~ear*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.

 

This concludes the configuration in the SSO System.

Webdispatcher

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:

  • AUTH_SYSTEM=<SID>
    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
      JSESSION.*
    • ABAP
      SAP_SESSIONID_APP_.*

HTTPS Setup

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

Backend-Systems

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
    icm/HTTPS/trust_client_with_subject
    icm/HTTPS/trust_client_with_issuer
    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

Troubleshooting can be done with the following tools:

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

Webdispatcher:
In the webdispatcher you can use the webdispatcher trace level or, if necessary, the icm-Request-logging (https://help.sap.com/saphelp_nw74/helpdata/en/58/601269a62d4493aea63a9584f6ae26/content.htm)

Backend:
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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

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

    (1) 

Leave a Reply