SMP 3 Security – Principal Propagation



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:

SMP3 Security - Principal Propagation.png

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.


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


  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.




icm/HTTPS/trust_client_with_issuer, CN=MyCA, OU=MIT, O=SAP, L=Walldorf, SP=NRW, C=DE

CA cert of SMP client


CN=smpClient, OU=MIT, O=SAP, L=Walldorf, SP=BW, C=DE

SMP client certificate

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


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:



To report this post you need to login first.


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

  1. Kishor Patil

    Thanks Marvin for the wonderful blog. Liked the way you covered the required steps with explanation of concepts/reasons behind them. In my case I wanted SAML-SSO to our custom web app written in Java instead of to SAP Gateway. I was able to do that after getting generic idea from this blog and from your other blog regarding SAML auth in SMP.

    Q1: Why is Principal Propagation called an authentication provider when it does not do authentication?
    Q2: After SMP does SAML authentication, is principal propagation only possible by sending X509 cert? Can’t SMP send a predefined header with username to backend? In cases like mine, in backed app I am only concerned about username of the authenticated user.

    1. Marvin Hoffmann Post author

      Hi Kishor,

      thanks, in regards to your questions


      Principal Propagation cannot be used as single Authentication Provider. It can always only be used in combination with a “real” authentication method. The same applies to e.g. the SAPSSO2 Provider or the Kerberos Provider… But I agree with you that the name (Authentication Provider) might be a bit misleading here.


      Like mentioned it should be also possible to use SSO2 or Kerberos (did not try it myself yet). Simply forwarding the username will be difficult. But what you could do, you could use the “Populate JAAS Subject From Client Provider” Authentication Provider, which is also not authenticating the user, but you can use this to read out header or cookies from the authenticating request and store them as variables inside the server. Inside the sso backend configuration you could attach them again as header or cookie… If I find some time I will try to write a blog post for this…

      1. Pavan Golesar

        Hi Marvin,

        This is a really helpful blog,Thanks for sharing !! 🙂

        Can you light up the path to solution for my query:

        Authentication issue in SMP from Windows AD (Ac… | SCN

        current we are implementing SMP platform Native mobile app. I required your advise and suggestions for below scenario :

        Current design :

        Have ECC (Installed in different box) and NW (installed in different box) trusted RFC connection maintained between ECC & NW to consume ODATA services.

        1) Our mobile app will authenticate through windows AD server. (user maintained / created as “MobileUser1” in AD and ECC server) *User id is same in both the servers

        2) Is it mandatory to maintain the same user “MobileUser1”  in (NW server) ? to access for creating the orders, pull / sync the data

        3) If we maintain “Mobileuser1” in NW server then how can we handle if AD user password changes then it’s mandatory to change and create the same password in NW & ECC??



        1. Marvin Hoffmann Post author

          In your case you need the same user in AD, Gateway and your backend system. This blog post is about principal propagation, that means that SMP will create a temporary user certificate and will use this user certificate (instead of user/pw) to authenticate the user at Gateway. Thus if AD password changes there is no need to change the user’s password on Gateway or backend system, because the user’s password is never used in this scenario. Beside Principal Propagation you could also use SAPSSO2 Generator. With SAP Logon Tickets there will be also no need for a maintained user password in Gateway/backend, see SMP 3 Security – SAPSSO2

  2. Naresh Chittoor

    Hi Marvin,

    We are trying with above your solution for our AD integration with SMP mobile app,

    Please help me in step 2, 3, 4 under preparation

    from where we can generate the user certificate for SMP?



    1. Marvin Hoffmann Post author

      You can create it by your own e.g. by using OpenSSL. For testing purpose you could also re-use the existing smp_crt keypair which is already available inside the SMP keystore…

      I described that as well above…

      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)…

      1. Naresh Chittoor

        Hi Marvin,

        Please suggest in step 3 & 4, certificates needs to upload in NW and SMP? what kind of certs required to upload in NW.

        Please advice to proceed further..




Leave a Reply