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:
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.
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.
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 sap.com/sso~nea~ear 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.
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.
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.
All other systems have two subparameters that are required/recommended:
The Webdispatcher should have
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
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
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:
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.
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.
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 sap.com/sso~nea~ear 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.
Webdispatcher
In the Webdispatcher, there are two types of systems in a NEA-configuration.
- One Auth-System
The SSO System, that authenticates the user and issues the certificate - 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_.*
- Java
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 = 2Backend-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.
- SAP Managed Tags:
2 Comments
| User | Count |
|---|---|
| 14 | |
| 13 | |
| 11 | |
| 11 | |
| 11 | |
| 11 | |
| 10 | |
| 9 | |
| 9 | |
| 7 |
