Under the expression “Single Sign-On” (SSO), there are often different aspects that are used interwoven. Of importance is first the aspect of digital certificates that can be used for an initial authentication against a server. In this case digital certificates are just an alternative authentication, instead of the more typical basic authentication or form-based authentication. The use of digital certificates for authentication has a very high set of prerequisites, the most important being (a) the configuration and usage of HTTPS and (b) installing the digital certificates into the secure store on each client. The single sign-on problem that digital certificates solve is only that of the initial authentication.

The second aspect after an initial authentication, is that authentication is required for each application that is started. How can the user-supplied authentication from the initial authentication cycle be reused when starting each new application? In this case, the user also expects a single sign-on working mode, where applications can be started with a new authentication cycle. This aspect is handled with logon tickets (MYSAPSSO2 cookies). After the initial authentication, the server will issue such a cookie, which is effectively just the user’s name digitally signed in such a way that whenever the cookie is presented again at the server, it will be accepted as a form of authentication. For all subsequent requests, also when new applications are started, this logon ticket is part of the request to the server, thus carrying the authenticated user name.

Within the web context, digital certificates always refer to X.509 certificates. A digital certificate binds a public key to a distinguished name that is issued by a certificate authority. The important aspect here is that a certificate is so constructed (digitally signed by a certificate authority) that the receiving party can again validate the distinguished name. The distinguished name itself is usually of the form C=<country> O=<company> CN=<certificate_name> and can include other attributes that uniquely name a person. There are standard procedures whereby a company can obtain and issue such certificates to each employee. The first step is to import the certificate into the browser. With this, the browser now has our identity in a digital format that can be verified again by the server. The next step is to update the ABAP server be able to map the distinguished name onto a user name. This mapping can be configured with transaction SM30, in the table VUSREXTID. The external ID is the distinguished name from the digital certificate and must be entered exactly the same into the table, including the preservation of case and spaces.

The browser must now send the certificate to the server: The moment the protocol is switched from HTTP to HTTPS, the certificate is automatically sent as part of the encryption layer used to secure the HTTPS connection. No further work is required.

The switching from HTTP to HTTPS is triggered by the logon application that is configured within the ICF tree for the NWBC node. This logon application will (in its default configuration) as a first step in the authentication process do a protocol switch (only if HTTPS is available on the server). If then a digital certificate is provided that can be mapped onto a user, the authentication process is completed automatically.

As the configuration of HTTPS, the use of digital certificates and logon tickets are very closely related, all relevant documentation links to the security documentation will be provided in Configuring Authentication on the Server.

For detailed information in configuring SAP’s servers to use digital certificates, refer to referenced documentation. However, a few small topics that are very relevant for NWBC when using digital certificates we wish to highlight here. These are the option of using SAP’s Passport service to obtain digital certificates, the prerequisite to Microsoft hotfix 919477 when using digital certificates and a highlight of how certificate mapping needs to be configured on the server.