SAP Single Sign-On (SSO) free of charge for web applications

Published on 9. April 2022

In my article SAP Single Sign-On (SSO) – free of charge I described how to configure Single Sign-On for SAP ABAP. In this article I would like to describe how to configure Sigle Sign-On in an ABAP system for web applications, such as the webgui.

Requirements

In order for users to be able to log on to a web service using a certificate, some requirements must be met. I have summarized these here:

Certificate (+ private key) must be available to the user
SAP system must accept certificates for logon
The SAP web server must trust the certificate issuer
The SAP Web service must be configured for certificate-based logon
A mapping to the user must be made above the attribute of the certificate
For the SAP user, the mapped attribute must be stored in the user master record.

Windows AD – Distribute user certificates automatically

The configuration for the “Certificate Auto Enrollment” is configured via a group policy and the certificate service of the Active Directory. In this example, the Active Directory server is a Windows 2016 server system.

Configure group policy for automatic enrollment

The following configuration is relatively simple, but should be well considered in the settings.

First, we create a new group policy and enable “Certificate Autoenrollment” in this policy.

For this we start the Group Policy Management Console(gpmc.msc)

Create a new GPO via Group Policy Management Console. — Group Policy Management Console

The policy can be found at: User Configuration | Policies | Windows Settings | Security Settings | Public Key Policies –> Certificate Services Client – Auto Enrollment can be found.

SAP Single Sign-On (SSO) for Web Services - free with certificates 1 — User GPO for Certificate Service Client – Auto Enrollment

In addition to the activation, the checkboxes for renewing and updating certificates should be set.

With “Renew expired certificates”, autoenrollment renews certificates if the certificate templates are not set up for autoenrollment.

These are templates that require multiple signatures (e.g. Enrollment Agent) or accept certificate subject information from the application. In addition, this setting retrieves pending applications that have been set to pending status for approval by the CA Manager.

By “Update certificates that use certificate template” Auto Enrollment registers and renews certificates based on certificate templates that have been set up for Auto Enrollment. If this option is not enabled, none of these tasks will be performed during auto-enrollment activation.

Certificate Services Client - Auto Enrollment Configuration — Configuration of: Certificate Services Client – Auto Enrollment

This configuration can also be set under “Computer Configuration” if server certificates are to be created automatically.

Finally, this GPO must be linked to the corresponding GPO where it is to take effect.

SAP Single Sign-On (SSO) for Web Services - free with certificates 2 — GPO linked to OU user

Configure and activate certificate template

To create the certificates automatically, we need a certificate template. Via certsrv.msc we can manage the templates. We can manage them via the context menu of the “Certificate Templates”.

SAP Single Sign-On (SSO) for Web Services - free with certificates 3

Create a duplicate of the existing user-only signature template so that the delivered templates are not changed and the default settings can still be checked afterwards. The name of the duplicate is then adjusted via “General” according to your own naming conventions.

When configuring, it is important to consider how I want to authenticate and how I can increase security.

The most important configurations are performed via the General, Subject Name and Request Handling tabs.

SAP Single Sign-On (SSO) for Web Services - free with certificates 4 — Certificate validity

SAP Single Sign-On (SSO) for Web Services - free with certificates 5 — Certificate validity

General” tab

In the “General” tab, the validity period and the publication of the certificate are configured. For the validity period, I recommend a manageable period of 3 to 6 months. It must be remembered that if an employee leaves the company or changes his or her name, the certificate still retains its validity and this is not desirable.

In addition, one would like the publication in the Active Directory.

Subject Name” tab

These configurations are later for the certificate mapping in the SAP system. For this article, the configuration is to be configured by e-mail address. However, authentication via the Microsoft User Principal Name (msUPN) or the Common Name (CN) would also be conceivable.

The User Principal Name is similar to the e-mail address, but is usually configured with the internal domain name. But it could also be the same as the e-mail address. UPN could be interesting if the UPN user name is the same as the SAP user name. Then you could use the “PrincipalOnly” via the parameter ccl/snc/server_partner_name_x509 (see also under: Related links).

The “Subject Name Format” can use either the “Common Name” only or the “Fully distinguished name”. I can set a filter via the latter in the SAP systems that only allows a specific OU hierarchy. More about this in the SAP configuration.

Request Handling” tab

In principle, the default settings are already good. The private key should be marked as “exportable” only in important cases. The private key is a prerequisite for certificate enrollment. With this I would allow users to store this certificate on x arbitrary machine. This should be avoided.

With this configuration, you are already well positioned. One has a certificate and can later map the user with the SAP user via three characteristics.

Check user certificate

Once the Active Directory settings have been made, it is time to log in with a Windows user and check the automatic certificate issuance. (This user should of course also have the group policy for the automatic certificate assigned).

For this user, if necessary. the first time you log in, the group policy must be enforced again –> gpupdate /force /target:user.

Via certmgr.msc the newly created certificate should then be visible under “Own certificates” and show the desired features from the certificate template.

Certificate in the user store of the user

The characteristics of the certificate:

Certificate details - Subject — Certificate Details – Subject (Applicant)

Certificate details - SAN — Certificate Details – Subject (Applicant)

Contrast this with the AD user:

AD user and its UPN — AD user and its e-mail address

If the certificate is issued automatically with the desired characteristics, it is possible to configure them in SAP ABAP for logon.

Configure SAP Netweaver AS ABAP

A prerequisite for the SAP system to accept certificates for logon is that the “Server SSL PSE” is configured in transaction STRUST. And this is ideally signed by the same certificate issuer as the user certificates.

STRUST - SSL Server Standard — STRUST – SSL Server Standard. The issuing CA of the certificate must be trusted.

In this case, there are (deliberately) two CAs that are trusted.

If the SSL Server PSE is configured, only the icm/HTTPS/verify_client parameter needs to be configured to accept user certificates. With the value 1, the server optionally accepts user certificates, but jumps back to Basic Authentication if needed. With the value 2 I could force a certificate-based login, with 0 I could disable it completely.

It is important to keep in mind that certificate-based logon depends on the particular web service and its logon method. By default, this certificate-based login is one of several, so nothing needs to be configured on the service.

Since certificate-based login can only be performed via HTTPS over a secure channel, you should consider performing an automatic redirect from HTTP to HTTPS if necessary.

However, the most important parameter is probably login/certificate_mapping_rulebased. This enables the mapping of certificate properties to SAP user IDs via the TA CERTRULE. By default, mapping for individual users would have to be done via the USREXTID view in SM30. Which can be very time-consuming.

Profile parameters

icm/server_port_1                    = PROT=HTTPS, PORT=443$$ , TIMEOUT=60 , PROCTIMEOUT=120
icm/HTTPS/verify_client              = 1
login/certificate_mapping_rulebased  = 1 

# Optional
icm/HTTP/redirect_0   =  PREFIX=/, FROM=/sap/bc/*, FROMPROT=http, PROT=https, HOST=$(LOCALHOSTFULL),PORT=443$$

Create certificate rules for automatic enrollment – TA CERTRULE

The transaction CERTRULE helps you to create rules for the mapping via wizard and existing certificate. This is not possible without an existing certificate!

To create the first rule, load the user certificate. To do this, click on the selection button to the right of the “Subject” field and specify the user certificate.

In the right field you can read two important pieces of information: 1. there is a rule for this certificate (mapping status) and 2. If necessary, a user is mapped via the rule.

Create a rule about an existing certificate

To create the first rule press the corresponding button, this will analyze the certificate and 4 filter criteria will be available.

CERTRULE - Create a rule using SAN — CERTRULE – Create a rule based on the subject or subject alternative name (SAN)

The certificate entry is used to select the field over which the attribute to be mapped is to come. Via the Subject or Subject Alternative Name field. The Common Name would be selectable via the Subject field. However, mapping an SAP user name over it will probably be difficult.

However, the Subject Alternative Name with the certificate attributes rfc822Name and msUPN can be perfectly mapped with Login As and the email address. As an alternative to the e-mail address, the SAP user ID or alias can also be configured for the logon.

CERTRULE - complete rule set — CERTRULE – complete rule set

Last but not least, you can use the Subject Filter to limit or set the group of people that will be automatically logged in with this rule. If you don’t want this at all, you can have the Common Name set in the certificate template instead of the Fully Distinguishedname.

In the example shown above, the Distinguished Name is: “CN=Andy Niemann, OU=User, OU=ORG, DC=testlab, DC=local”.

With the filter used above, this rule would allow all users in the AD structure “OU=User, OU=User, OU=ORG, DC=testlab, DC=local” to log in with a certificate. If I want to allow all users in the “OU=User” to log in via certificate, I only need to remove the entry “OU[4],” in the Subject Filter. Instead of “OU=User” it then usually says “CN=*,OU=*,OU=User …”.

Once the rule has been created and saved, the certificate can be used to check whether the following is true a) a rule exists for this certificate and b) whether a suitable SAP user is then also found. By the way, it is also displayed if the e-mail address exists multiple times (keyword test user).

CERTRULE - Complete rule and successful display of the mapped user. — CERTRULE – Complete rule and successful display of the mapped user.

Automatic certificate selection in the browser

In order for users to log in automatically using the certificate, you can set a corresponding registry key for the Edge or Chrome browser.

For this purpose, the AutoSelectCertificateForUrls key must be created, for example, at [HKLM]SOFTWARE\Policies\Microsoft\Edge\. Below this branch, consecutive Reg_SZ entries can be created with the names 1,2,3 … can be created.

The values can be filtered by URL, certificate issuer or certificate subject. Note that wildcards cannot be used to search for matches to parts of schemas, domains, hosts, ports or paths!

This means that, for example, you cannot filter on the /sap/bc/* path. Too bad actually.

Registry examples for AutoSelectCertificateForUrls

The following examples show the possibilities and application examples

{"pattern":https://*,"filter":{}}

With this example, the certificate is basically transmitted automatically on every HTTPS page. There is only one filter on the HTTPS scheme. If multiple certificates are available, a pop-up window with a selection list will come up.

{"pattern":https://[*.]testlab.local:*/*,"filter":{}}

With this entry we set wildcards for hosts and subdomains ([*.]) in the domain testlab.local. A wildcard is also set for the ports. The path is released generically here.

{"pattern":https://[*.]testlab.local:*/*,"filter":{"ISSUER":{"CN":"Testlab-CA", "DC": "testlab", "DC": "local"}}}

In this example, a filter on the certificate is now used for the first time. It makes sense to use only certificates issued by the internal CA.

{"pattern":https://[*.]testlab.local:*/*,"filter":{"ISSUER":{"CN":"Testlab-CA", "DC": "testlab", "DC": "local"},"SUBJECT":{"OU": "cert-user", "OU": "user", "DC": "testlab", "DC": "local"}}}

SAP Netweaver AS JAVA

For SAP AS Java systems the profile parameters are basically the same as for a SAP ABAP system (see here). We only need the ABAP-specific parameter ~~login/certificate_mapping_rulebased~~ not.

The following configuration requires an already configured HTTPS service. The configuration is performed in AS Java Netweaver Administration.

The first step is to configure the certificate mapping in the Authentication and Single Sign-On menu. Then the configuration is completed in the SSL menu.

SAP Netweaver Administration: Configuration

Configure certificate enrollment

In the Authentication and Single-On menu item, the configuration is made in the default policy ticket and the login module ClientCertLogin.

SAP Netweaver Administration: Authentication and Single Sign-On

If the modules are not already present, they should be added first in this order: EvaluateTicket (Sufficient), ClientCertLogin (Optional), CreateTicket (Sufficient), BasicPasswordLogin (Requisite), CreateTicket (Requisite).

This arrangement first checks for a valid logon ticket, optionally offers a certificate-based logon, and falls back to a password-based logon in the event of an error, and creates a ticket if the logon is successful.

Authentication and Single Sign-On - ClientCertLogin Module — Authentication and Single Sign-On – ClientCertLogin Module

The rules for certificate-based logon and automated user mapping take place via rules in the ClientCertLogin module.

To add entries, the policy ticket must be released via “Edit”.

Then, for example, the following rules can be created.

issuer                       CN=winsvr16,DC=testlab,DC=local
#msUPN
Rule1.AttributeName		     OID=1.3.6.1.4.1.311.20.2.3
Rule1.getUserFrom		     expertMode
Rule1.OID				     2.5.29.17
Rule1.UserMappingMode	     Email

#RFC822
Rule2.AttributeName		     rfc822Name
Rule2.getUserFrom		     expertMode
Rule2.OID				     2.5.29.17
Rule2.UserMappingMode	     Email

#User Certificate
Rule3.getUserFrom		     wholeCert
Rule3.filterIssuer		     CN=another-server,DC=domain,DC=intra

The certificate entry SubjectAlternativeName is addressed with the OID 2.5.29.17. The attribute is then selected by name, e.g. rfc822Name, or in the case of the User Principal Name by OID, and automatically mapped to the user’s e-mail address.

Rule 3 provides for the possibility of manual certificate mappings here. The user must be provided with a certificate in the user master. This can be useful, for example, for service users or users of service providers who do not receive an automatic certificate.

SSL service configuration

Finally, the SSL service needs to be customized. First, make sure that the client authentication is set to “Request”. This should actually already have been configured by the profile parameter icm/HTTPS/verify_client.

More importantly, the certificate chain (root CA and sub-CA, if applicable) is stored in the “Trusted CAs” tab. Only then are the accepted CAs (and their issued certificates) transmitted to the browser.

SAP Netweaver Administration: SSL Configuration

Good luck with the implementation and satisfied users!