Skip to Content

The upcoming release of SAP NetWeaver Process Integration (SAP PI) supports standards like Security Assertion Markup Language (SAML), and Web Service Reliable Messaging (WS-RM). This blog describes the Principal Propagation solution for the WS-RM protocol which is based on SAML.

What is Principal Propagation?

Principal propagation allows to securely pass the identity of a user from a sender application to a receiver application. For the mediated scenario (via SAP PI) using the new web service reliable messaging protocol for instance, this means that the web service on the web service provider system runs under the same user as the web service consumer application.

So far, user credentials are statically configured in destinations and channels. With Principal Propagation this can be done dynamically, reducing maintenance effort and leading to more flexibility. Furthermore, it’s possible to verify the permissions of the original user within the receiver application, and to audit the user in the receiver system.

The following adapters and protocols support Principal Propagation: XI, RFC, SOAP, and WS-RM. Principal Propagation for XI, RFC, and SOAP is based on the SAP assertion ticket, see also blog about Principal Propagation in SAP XI. The WS-RM approach uses SAML assertions.

What is SAML?

SAML is an XML standard defined by the Organization for the Advancement of Structured Information Standards (OASIS). It is used to exchange security information between a service provider and an identity provider. SAML is based on assertions containing statements about a subject (usually a user). Those statements could either refer to an authentication, attribute information, or authorization permissions. For Principal Propagation, we only focus on authentication statements.

The OASIS Technical Committee defined so called profiles to support different usage scenarios, like Web Browser Single Sign On, or Securing Web Services. For latter, the SAML token profiles were introduced. They define how web service authentication is established at the SOAP message level, i.e. how the SAML assertion is integrated into a SOAP message.

To verify an assertion, a trust relationship between the web service provider (here the receiver of a message) and an attesting entity has to be established. The attester vouches for the correctness of the SAML assertion, hence he has to sign it. An issuer actually issues the SAML assertion. The receiver has to trust him as well. SAP NetWeaver supports the Sender Vouches Subject Confirmation method to verify a subject with SAML token profile authentication. In this scenario, issuer, attester and web service consumer (here the sender of a message) can be regarded as one entity. So, the sender generates the assertion on his own. A sender-vouches SAML assertion is added to the message. Both the assertion and the message body are signed using the sender’s private key. So, the sender vouches for the correctness of the message content and the SAML assertion, i.e. he vouches for the identity of the subject. The receiver authenticates the user based on its trust relationship with the sender.

The overall mechanism

In the following, the Principal Propagation approach using SAML sender-vouches profile is decribed in more detail. Here, principal data should be propagated from a sender system to a receiver system via SAP PI.

The issuer generates and provides a SAML assertion which is added to the message. It contains the subject name. The identity is described by a well defined XML tag that contains information about the principal name, the SAML issuer, and the SAML attester.

The sender acts as the trusted attester, and signs the assertion using its private key. The sender also signs the message itself. So, the sender vouches for the integrity of both the SAML assertion and the message content. As a prerequisite, a trust relationship between sender and the Integration Server has to be established so that the Integration Server is able to verify the sender’s digital signature.

Beside the trust relationship to the attester, a mapping of the subject name to the actual user in the Integration Server has to be maintained.

The message containing the SAML assertion is sent to the Integration Server using the WS-RM protocol. On message receipt, the Integration Server attempts to verify the SAML assertion. If the assertion is incorrect, the message is rejected, and an error is sent back to the sender. Otherwise, the principal data of the SAML assertion is read, and the message is processed within the Integration Server. Beside checking the correctness of the SAML assertion, the Integration Server also has to verify that the issuer is trustworthy, and that a trust relationship between sender and the Integration Server exists.

After message processing within SAP PI, the message is sent to the final receiver. In order to propagate the user identity to the receiver, the Integration Server has to create a new SAML assertion containing the original principal data. So, here the Integration Server acts as the SAML issuer and attester. Similar to the PI inbound side above, the receiver has to trust the Integration Server.

On message receipt, the receiver checks the SAML assertion, and verifies that the issuer is trusted. If successfully verified, the user is impersonated and logged on to the receiver system.

How to configure?

In general, you have to configure two trust relationships. First of all, the web service provider (i.e. the receiver of the message) has to trust the consumer (i.e. the sender of the message) or the Certificate Authority (CA) that issued the signature. Furthermore, the provider has to trust the issuer of the assertion, hence the user that is subject of the assertion.

To exemplarily describe the required configuration steps, I focus on the PI inbound side: A web service consumer sends a message to the WS-RM adapter of the Integration Server. Authentication is done by SAML assertion which is added to the message. The following configuration steps have to be carried out. Select the respective links to watch the recordings of the different configuration steps.

To report this post you need to login first.

5 Comments

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

  1. Markus Karsch
    Hi Alex,

    it’s me again 🙂 I have configured a scenario with non-SAP WS sender with SAML activated (testing with soapui as sender client) and SAP RFC as receiver in PI 7.11 SP2. Configuration I have tested successfully with normal authentication and soapui before. When switching to SAML I get only an error response “Logon Error Message” with no detailed information. Traces in SOAMANAGER do not show any entry, in SMICM I can see the request but no detailed traces why authentication failed. Do you know where I can find detailed traces? Certificate used in soapui client is imported to STRUSTSSO2 and I have executed report RSUSREXTID for my userid in PI.

    Regards
    Markus

    (0) 
  2. Michal Michalski
    Hi Alexander,
    Thanks for sharing the PProp knowledge.
    I have one doubt concerning user mapping.
    In one of the SAP PProp tutorials I found that user has to be the same in every system that takes part in PProp scenario. Meaning that in Sender the user name has to be ‘BOB’ on SAP PI the user has to be ‘BOB’ (with proper role) and finally on receiver system the user has to be ‘BOB’. Do you mean that report RSUSREXTID executed in provider/receiver (providing that it is a SAP ERP system) allows us to perform a scenario where we have a connection: sender/user: ‘BOB’ -> SAP PI/user: ‘BOB’ -> receiver/user: ‘MICHAL’ ?
    (0) 
    1. Alexander Bundschuh Post author
      Hi Michal,

      in general, the user mapping should work for the SAML Principal Propagation approach, i.e., you can have different user names, however as far as I know the report RSUSREXTID does not support it, so either you have to write your own report or directly maintain table view VUSREXTID.

      Regards
      Alex

      (0) 
  3. Rene Pilz

    Hi Alexander,

    one question:

    We do want to generate SAP SSO Login Tickets with out PI, is this also possible with a similar way? Is it also possible to change the “user” in the Login Ticket within a Mapping?

    Meaning: We do have a Webservice-Request from an outside System that connects using user “abc” to our PI. Now we want this Webservice-Request to call a Webservice on a SAP Portal with the user “xyz”.

    In our Mapping we do have a conversion-table that describes this abc => xyz mapping.

    Thx,

    Regards

    Rene

    (0) 

Leave a Reply