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.
