Principle Propagation between BTP and SuccessFactors - Oath token searches LMS_USER_00001

[emanuelvynck]

Hey all

We're trying to set up a connection between SAP BTP and SuccessFactors Learning, but the principle propragation is not working as expected. The OAuth token issued by SFSF causes issues while requesting the users learning plan and is suddenly searching for a whole different userID: LMS_USER_00001. We cannot figure out why our setup is behaving like this, and we appreciate any insight or suggestions you might have.

OUR SETUP:

We do have a working Trust Relationship between our BTP subaccount and our SFSF system. We did this by setting up an OAuth client in SFSF. Further we do have a destination setup of type OAuth2SAMLBearerAssertion. We believe that the destination is setup properly since if we do provide a proper SystemUser (admin user in SFSF), we do receive a working OAuth token which we can use for subsequent requests towards the SFSF API.

Here is an example of the WORKING destination (called via destination api). Please pay attention to the SystemUser property which is set to a hardcoded SFSF user id. The obfuscated Bearer token is valid and accepted for subsequent calls.

If we do now remove the SystemUser property (in order to use REAL principal propagation), things are not working properly. Let’s first take a look at our destination configuration and the way we request the OAuth token.

Please note, that the SystemUser property is now gone. Instead, we are providing the X-user-token header with the user’s XSUAA token (we will show the content of the token in a minute). The nameIdFormat property is set to unspecified, which according to the documentation, will use the “user_name” property of the user’s XSUAA token.

This is the content of the User token which we pass to the destination service within the X-user-token header. As you can see the expected user_name property is present and also contains the correct SFSF userid. So we do have the ingredients to do proper principal propagation and map the XSUAA users to the appropriate SFSF users.

But if we perform a request to the learning plan service, we do receive this error message: USER INVALID: LMS_USER_00001

Please note, that we pass the bearer token which we obtained from the previous destination service request within the Authorization request header. We can’t comprehend this odd behavior. Why are we receiving this error?

If we use the same Bearer token for e.g. the $metadata service request, we do receive proper data. Please have in mind, that this service is rather user independent. Where the previous Learning Plan service requires a proper user context to work. But at least it tells us that we are authenticated towards SFSF:

I hope that this explains our current issue properly. Please let me know in case you need additional information. Other than that we would be very thankful if anyone could provide help to resolve our problem.

Many thanks
Emanuel

[pieterjanssens]

I see minor differences with my working SF LMS destination, try setting audience to 'www.successfactors.com' and add a property 'XFSystemName' with the SF instance ID as value.

What does /oauth/validate tell you on the HXM Core (BizX) API host?

[quovadis]

Hello,

From the screenshots enclosed I can see the user id from SystemUser (ending 68) is not the same as the one from the xsuaa jwt (ending 97).

Moreover in the latter case there is also a scope (=authorization) value set.

Can you rehearse the user id from the xsuaa jwt as a SystemUser in your initial destination definition ?

Does it work as expected ?

You could also try to do it the other way, namely to create a jwt token for your user id (ending 68) and try out the 2nd destination definition.

I hope that helps; regards; Piotr