SMP 3 Security – Principal Propagation

Topics

• Overview
• Preparation
• SMP Configuration
  • Using SMP’s base Certificate
• Debugging

Overview

Principal Propagation is a Single Sign On possibility. When a user got already authenticated SMP can use Principal Propagation to create a temporary user certificate and then use this user certificate for connecting to the backend system. The backend system would then create a session/context based on the user certificate. SMP needs for this a CA certificate that can be used to create X509 user certificates. It can be configured how the distinguished name of the user certificates should look like. Usually SMP would insert the user name (of the currently active SMP session) as the common name (cn). This temporary created user certificate has a limited lifetime (e.g. 10 minutes) and will be transferred in a header called SSL_CLIENT_CERT to the backend system. The backend system needs to be setup for client certificate authentication, SMP needs to be trusted as well as SMP’s CA certificate. Additionally the connection between SMP and the backend should be secured by mutual https connection.

The process is described in following picture:

1) Data Request

A request is sent to SMP, e.g. a GET Request to receive some data from backend system

2) SMP Authentication

SMP will authenticate the user by applying the specified Authentication Providers. Inside the Security Profile there also needs to be defined the Principal Propagation Authentication Provider. the Principal Propagation Module cannot be used alone inside the Security Profile. It must be used in combination with another Authentication Provider that is authenticating the user (e.g. HTTP/HTTPS Authentication, LDAP, SAML2, …)

3) Temporary User Certificate Creation

The Principal Propagation Module will then get the username (of the already authenticated user) from the current session and will create a user certificate (by using a specified CA certificate from SMP’s keystore)

4) Request to Backend System

SMP will establish a mutual https connection to the backend system. That means, that SMP will use a (beforehand defined) client certificate to connect to the backend system. After that SMP attaches the created X509 user certificate as base64 encoded string into the header SSL_CLIENT_CERT and forwards the request to the backend system.

5) Backend System

The backend system receives the request and recognizes that a user certificate is given inside the SSL_CLIENT_CERT header. Because SMP got setup as trusted system and also the CA certificate is trusted, the backend system is using this user certificate to create a user session. There has to be a user/certificate mapping in place, so that the user certificate can be mapped to a concrete existing backend user.

6) Data Response

Backend system has now a valid session and will return the requested data

7) Data Response

SMP will forward the data response to the mobile device.

Preparation

In the following I will described the process for Principal Propagation in combination with a SAP Gateway.

Make sure that SSL is enabled on the Gateway server. Steps for this are described for example in following post:
Enabling SSL (HTTPS) on SAP Gateway .

Also test before if your Gateway system is prepared for certificate based authentication. Required steps are described here:

Configuring Client Certificate Authentication (mutual https) on SAP Gateway

Steps

1. Create (technical) user for SMP on Netweaver Gateway (in my case SMPCLIENT)
2. Create a user certificate for SMP (that is accepted by Netweaver Gateway)
   Test it by using transaction CERTRULE and importing SMP user’s certificate
   
3. Create a CA certificate and key which can be used by SMP to create/sign temporary user certificates.
   Check if certificates created by this CA keypair are really trusted (and mapped) in Netweaver Gateway. If not create a new rule in CERTRULE
   (In my case my CA is called PrincipalPropCA)
   
4. Import both cert/key pairs (smpClient and PrincipalPropCA)  as .p12 files into SMP’s keystore
   e.g. by using KeyStoreExplorer or since SP08 by using the Certificate tab in Management Cockpit
   
   Remember the given alias names (required in later steps)
   You should stop SMP server, then change the keystore and then restart the server again
5. 5. Import PrincipalPropCA into your Server PSE in STRUST
    
6. 6. Add to the Gateway’s profile parameter the following parameters (in RZ10)
   (Server Restart required)
   Without these values SAP Gateway will not accept the user certificates sent inside the SSL_CLIENT_CERT header.

Values can be found inside the client certificate that is used by SMP to establish a mutual https channel to Gateway.

Tip: I recommend checking the exact values inside dev_icm log, because the string has to match exactly the sender, so e.g. if a space is missing it is not working. Simply execute it once, and check with ICM Trace set to 2. (see Debugging section)

Using SMP’s base Certificate

For testing scenarios you can also use smp’s base certificate: smp_crt
It is also tagged as CA certificate. You could use it for both (smp client as well as principal propagation CA).

But this should be only used for testing/development purpose…

SMP Configuration

Quick Overview

• Security Profile contains two Authentication Providers
  (Principal Propagation is not authenticating the user)
• The Subject Pattern in Principal Propagation Auth Provider Settings needs to be setup in the backend system as user mapping (usually Subject DN of X509 certificate)
• In Backend Configuration add the certificate alias which identifies a certificate (private key required) in SMP‘s keystore that is used by Principal Propagation Auth Provider to create the temporary user certificate
• In Backend configuration add „X509“ as SSO mechanism
• After the user got authenticated (by the first auth provider) the Principal Propagation Auth Provider will create a temporary user certificate for this specific user. This temporary user certificate will be attached as Header SSL_CLIENT_CERT to request against the backend
• The communication between SMP and backend should be encrypted by mutual HTTPS

Steps

Create a new app which points e.g. to an odata service from netweaver gateway. Choose as SSO mechanism “X.509”. Additionally you have to set the “Certificate alias”. Here you have to specify the alias name of the key pair which will be used to establish the mutual authentication channel between SMP and backend.

Additional information to SSO Mechanism (from SAP Help): X.509 Certificates

• Connects to the back end using the configured technical user X.509 certificate. The end-user certificate is passed in the SSL_CLIENT_CERT HTTP header. Configure the back end to allow the technical user to impersonate the end user and execute the request in the context of the end user. The end-user certificate may be generated by the Principal Propagation provider that is configured in the security profile, or it may be supplied by the end user when he or she authenticates to the server over a mutually authenticated HTTPS connection. You can use this mechanism with either the X.509 authentication provider or the Principal Propagation provider that is configured in the security profile.

Add a new security profile. Inside the Security Provider use an authentication provider to authenticate the user (in my case SAML2), then add Principal Propagation module as second provider

The Subject Pattern of the user certificate can be chosen. ${name} is the variable which gets replaced during runtime with the current authenticated username. This user certificate will be valid for 10 minutes only. It will be signed by PrincipalPropCA (which is a CA certificate pair that we imported into SMP’s keystore.

Debugging – ICM Logging/Tracing

Especially if communication between SMP and Gateway is not working, it makes sense to have a closer look on what exactly has been received on Netweaver side. For that you can increase the log level of ICM and then use the dev_icm log to check what has been received.

Open transaction SMICM and choose Goto > Trace Level > Set

And set it e.g. to “2 Full Trace”

After that execute a failing request, then check ICM Trace File:

E.g. the following error is thrown, if SMP is not setup correctly as trusted system on SAP gateway: Intermediary is NOT trusted / Reject untrusted forwarded certificate

HttpModGetDefRules: intermediary is NOT trusted -> remove SSL header fields

Reject untrusted forwarded certificate (received via HTTPS with untrusted certificate): subject=”

HttpModHandler: remove incoming ssl header

So you can see here, that the DN of SMP’s client certificate is not exactly the same as that one we are trusting (missing spaces…). So we need to correct this in transaction RZ10: