This repository contains the instructions (this file) and supporting material for the hands-on lab based on the blog post Principal Propagation between Microsoft Power Platform and SAP.
- Preparation
- System access
- Business scenario
- Exercises
- Exercise 1: Configure trust between Azure AD and the SAP backend system
- Exercise 2: Setup the OAuth Client for the Chatbot in the SAP backend system
- Exercise 3: Create the connection in Power Platform for the token exchange flow
- Exercise 4: Test the chatbot in Power Virtual Agent web client
- Exercise 5: Inspect the SAML assertion sent to the SAP backend’s OAuth server for the token exchange
- Exercise 6: Change the user's authorizations in the backend and test the scenario again
Make sure you meet the following prerequisites for the best workshop experience:
- Install SAP GUI on your local workstation and configure the connection to the SAP backend system (IP
20.105.160.185, SIDA4H) used in the workshop with the following parameters:
- Optional: Configure name resolution of the SAP backend's FQDN in your local hosts file by adding the following line:
20.105.160.185 vhcala4hcs.bestrun.corp vhcala4hci.dummy.nodomain
- Optional: To avoid security warning in the web browser, add the backend system's TLS issuer (CA) certificate to the trusted root authorities on your local workstation. For Windows, run
mmc.exe, add the Certificate Snap-in, and import the certificate to theTrusted Root Certificate Authoritiesfolder:
You will group in separate teams (1 to 10) that use the following user accounts for administrative access to the SAP backend system, Microsoft Power Platform and Microsoft Azure subscription:
| Team | SAP Client | SAP User | Power Platform |
|---|---|---|---|
| 1 | 001 | DEVELOPER1 | team1@bestruncorp.onmicrosoft.com |
| 2 | 002 | DEVELOPER2 | team2@bestruncorp.onmicrosoft.com |
| 3 | 003 | DEVELOPER3 | team3@bestruncorp.onmicrosoft.com |
| 4 | 004 | DEVELOPER4 | team4@bestruncorp.onmicrosoft.com |
| 5 | 005 | DEVELOPER5 | team5@bestruncorp.onmicrosoft.com |
| 6 | 006 | DEVELOPER6 | team6@bestruncorp.onmicrosoft.com |
| 7 | 007 | DEVELOPER7 | team7@bestruncorp.onmicrosoft.com |
| 8 | 008 | DEVELOPER8 | team8@bestruncorp.onmicrosoft.com |
| 9 | 009 | DEVELOPER9 | team9@bestruncorp.onmicrosoft.com |
| 10 | 010 | DEVELOPER10 | team10@bestruncorp.onmicrosoft.com |
The instructor will provide the required password credentials for the users in the table above.
In this workshop you will implement a complete business scenario by integrating Microsoft and SAP technologies. From the end-user's perspective, you will use a chatbot in Microsoft Teams that lets you search and order office equipment in a product catalogue managed in a corporate SAP backend system. Access to the product data in the backend is restricted to certain product categories on a user level. For example, Jane Smith may only be allowed to order batteries and desk lamps, and John Doe can only order chairs.
The main requirement from a functional and security perspective is to provide seamless and secure access between the chatbot and the backend system. The user must not be asked to provide any credentials when accessing the SAP backend to search the catalogue. Instead, the already logged-on user in the chatbot is securely propagated to the backend system. This requires a two-step security token exchange:
- The token issed to the bot by Azure AD must be exchanged to a SAML assertion. This exchange is handled by Azure AD
- The bot uses the SAML assertion to seamlessly log on the user in the SAP backend system and request an OAuth access token. This access token issed by the SAP backend system for the user can be used to call the OData service for the search operation in the backend.
Please refer to the corresponding blog post of this lab for a detailled explanation of the technical flow in this scenario.
Estimated total time: approx. 60 min.
You will implement the exercises of the hands-on lab in an isolated team environment to complete the implementation of the business scenario. Due to time constraints, the environment is pre-configured. The following exercises focus on the most relevant configuration steps to gain a deeper understanding of the different components and their integration.
Make sure you have a team number (1-10) assigned before starting with the exercises. Ask your instructor for help if needed.
Estimated time: 15 min.
Start the implementation by setting up the required trust relationship between the business user's Azure AD tenant and the SAP backend system. Without this trust relationship, the SAP system would reject the SAML assertion issued by Azure AD and seamless single sign-on fails in the scenario.
| Step | Description | Screenshot |
|---|---|---|
| 1 | Open a browser and login to the SAML2 configuration of the SAP backend system with user DEVELOPERx (replace X with the team number assigned to you). Use the client assigend to your team (001...010). Note: If have not maintained your local name resolution as described above, use this URL and confirm the security warning in your browser. |
 |
| 2 | Select the Trusted Providers tab. |  |
| 3 | Select OAuth 2.0 Identity Providers from the drop-down list. |  |
| 4 | Choose Add -> Upload Metadata File. |  |
| 5 | Open a new tab in the browser and login as user teamX@bestruncorp.onmicrosoft.com to the Azure AD admin center. Select Enterprise Applications from the navigation menu. |  |
| 6 | Select the application ABAP 1909 A4H CAL 00x (with x replaced by your team number) from the list. |  |
| 7 | Select Single sign-on from the navigation menu and click on the Download link next to the label Federation Metadata XML. Store the metadata file on your local workstation. Repeat the step and download the Certificate (Raw) file as well. |  |
| 8 | Go back to the previous browser tab and upload the Azure AD federation metadata file (ABAP 1909 A4H CAL 00n.xml).Click Next. |
 |
| 9 | Select the option Upload from file and upload the raw certificate file (ABAP 1909 A4H CAL 00n.cer).Click Next. |
 |
| 10 | Click Next. |  |
| 11 | Click Finish. |  |
| 12 | Click Edit. |  |
| 13 | Under Supported NameID Formats click Add. |  |
| 14 | Select E-mail from the list. Click Ok. |  |
| 15 | Click Save |  |
| 16 | Click Enable and confirm with Ok. |  |
Estimated time: 5 min.
You have now successfully established the trust relationship. For exchanging the SAML assertion into an OAuth access token, the SAP backend system also requires OAuth client credentials (a client id and secret) to authorize the calling system (i.e. the chatbot) to act on behalf of the user. OAuth client credentials are bound to a system user in the SAP backend which will be created next.
| Step | Description | Screenshot |
|---|---|---|
| 17 | Open a new tab in the browser. Login with your client (000 ... 010) and user DEVELOPERx (replace x with the number of your team) to the OAuth2 configuration in the backend system. Click Create. Note: If have not maintained your local name resolution as described above, use this URL and confirm the security warning in your browser. |
 |
| 18 | The system user CHATBOT is alread created in the backend system. Select it for the field OAuth Client ID. Provide a brief description (e.g. Chatbot OAuth client). Click Next. |
 |
| 19 | Deselect the option SSL Client Certificate in the Client Authentication step and click Next. |  |
| 20 | Select the identity provider created in the previous exercise from the list. Click Next. |
 |
| 21 | The SAP backend requires the same scope(s) assigned to the OAuth client as requested by the user. Therefore select the OAuth scope ZPRODUCTSVIEW_CDS_0001 from value help list. This scope has been created with the deployment of the Core Data Services (CDS) view of the product catalogue search OData service.Click Next |
 |
| 22 | On the summary page, click Finish |  |
Estimated time: 10 min.
The backend system is now prepared to support the token exchange from the SAML assertion to an OAuth access token using the SAML 2.0 Bearer Grant Type. The chatbot delegates the token exchange logic with the SAP system to a flow in Power Automate. You will inspect the chatbot content and conversation logic with the Power Virtual Agents design tool and start from there to configure the connection to the SAP backend via the On-Premise Data Gateway in the the token exchange flow in Power Automate.
| Step | Description | Screenshot |
|---|---|---|
| 23 | In your web browser, login to Power Virtual Agents with user teamX@bestruncorp.onmicrosoft.com. |  |
| 24 | Open the Bot panel on the upper right corner and make sure to select your team's environment (Team X) from the drop-down list. Then close the panel. |  |
| 25 | Select Topics from the navigation menu. |  |
| 26 | Select the Product Search Topic from the list. The bot content opens in the canvas. |  |
| 27 | Take a moment to inspect the conversation logic of the bot. Scroll down to the action step where the user's JSON Web Token (JWT) is exchanged to the SAP OAuth access token using the Exchange Token Power Automate flow. Click on the View flow details link. |
 |
| 28 | The Exchange Token flow opens in Power Automate in a new browser tab. Click Edit. |
 |
| 29 | From the steps in the flow, select the second (Exchange AAD JWT to AAD SAML Assertion). This is the first step in the token exchange process where the user's initial JSON Web Token (JWT) from Azure AD is transformed into a SAML Assertion by Azure AD using the On-behalf-of (OBO) flow. |  |
| 30 | Scroll down to step #4 in the flow with the label Connections and the warning sign. Fix the issue of the missing connection by clicking New connection reference. |  |
| 31 | Enter the following values for the new connection:
Note: These are the credentials of the OAuth 2.0 client CHATBOT created in the previous exercise. The gateway system (BestRunCorpA4H) has been installed on the Windows VM and connected to the environment beforehand. |
 |
| 32 | Check the SAP client id in the URL of the request field. It must be set to the number of your team's client (e.g. "?sap-client=008"). Click Save. The issue is now fixed and the step details are shown. The step implements SAP's specification for the SAML 2.0 Bearer Assertion Flow from SAP. |
 |
Estimated time: 5 min.
You are now ready to test the chatbot in the Power Virtual Agent Test bot pane.
| Step | Description | Screenshot |
|---|---|---|
| 33 | Go back to the Power Virtual Agents browser tab. In the Test bot pane, enter one of the trigger phrases configured for your bot, e.g. "Purchase new office equipment". Click on the Send button. |
 |
| 34 | The bot sends the welcome message and asks for authentication. Click Login. |
 |
| 35 | A new browser tab opens to authenticate the user against Azure AD. Because your user teamX@bestruncorp.onmicrosoft.com is already authenticated, your are single signed-on. Click Copy to copy the validation code into the clipboard. Then close the tab. |
 |
| 36 | Paste the validation code into the chat and click Send. |  |
| 37 | The bot confirms the successful log and asks for a search term. Enter "DL" to search for products in the category "Desk Lamps" and click Send. |  |
| 38 | The bot starts the search by exchaning the tokens and finally calls the OData service in the SAP backend to retrieve the product items matching the search term. You can see how the conversation flow is executed in the canvas. Note: For debugging purposes, the bot prints out the OAuth access token generated by the SAP system. This should be omitted in a production scenario. |
 |
You have successfully tested the bot. Let's take a look now behind the scenes to understand how the seamless single sign-on (aka. principal propagation) works.
Exercise 5: Inspect the SAML assertion sent to the SAP backend’s OAuth server for the token exchange
Estimated time: 10 min.
The token exchange between Microsoft and SAP is the most crucial part in the scenario. If it fails, the seamless SSO experience is broken. In many cases, the setup of the SAML 2.0 configuration in Azure AD or the SAP backend is the root cause for such issues. For troubleshooting it is important to inspect the SAML assertion generated by Azure AD which is sent to SAP. In this exercise you will use the diagnostic tooling in SAP to get the required information.
| Step | Description | Screenshot |
|---|---|---|
| 39 | Open a new browser tab and login to the Security Diagnostic Tool in the SAP backend. Login with your team's client (001..010) and user DEVELOPERx (replace x with the number of your team). Note: If have not maintained your local name resolution as described above, use this URL and confirm the security warning in your browser. |
 |
| 40 | Click Start to start recording of the traces for SAML-based authentication in the system. |  |
| 41 | Go back to the browser tab with your bot. Click No in the chat to start a new conversation. |
 |
| 42 | Re-enter the trigger phrase ("Purchase new office equipment") and click Send. |  |
| 43 | Search again for products in category Desk Lamps ("DL") and click Send. |  |
| 44 | After successful response from the bot, switch to the Security Diagnostic Tool browser tab and click Stop. |  |
| 45 | Select the link of the generated trace file. |  |
| 46 | Scroll down in the trace file where the SAML Assertion is shown. The tool nicely formats the XML content to enable better inspection and troubleshooting. Take a look for example at the NameID element in the assertion. It contains the username of the Azure AD-authenticated user ("teamX@bestruncorp.onmicrosoft.com") and has the format of an e-mail address. |  |
| 47 | This value must match a local (SU01) user and her e-mail address in the SAP system. If you scroll at the end of the trace file you can see how the system is successfully mapping the incoming username from the assertion to the user ("TEAMx") in the backend system. |  |
Estimated time: 10 min
In this last exercise you will change the user's authorizations in the product catalogue by chaning the corresponding authorization object for the product category. After applying the changes you will re-test the scenario with the chatbot.
| Step | Description | Screenshot |
|---|---|---|
| 48 | Open SAP Logon pad and login to the backend system with your client (001-010) and user DEVELOPERx (replace x with the number of your team). |  |
| 49 | Start the Role Maintenance with transaction code "PFCG" |  |
| 50 | Enter "PRODUCT_SEARCH" in the role entry field and click the Pencil symbol to go into change mode. |  |
| 51 | Click the Pencil symbol next to the label CHange Authorization Data. |  |
| 52 | Browse the tree view for the fields of the S_EPM_PD authorization object. Click the Pencil symbol for the PDCATEGORY field which limits access to only the selected product category for the user. |
 |
| 53 | Click the *Value Help button next to the current value ("Desk Lamps)) to see the list of possible product categories to limit access to. |  |
| 54 | Select a different category (e.g. "Batteries") and click Copy (the green check mark button) |  |
| 55 | Click Save. |  |
| 56 | Click Generate. |  |
| 57 | Click Save. |  |
| 58 | Go back to your last conversation with the chatbot in the browser tab and click No. |  |
| 59 | Click Rephrase. |  |
| 60 | Enter a trigger phrase (e.g. "Search the product catalogue") and click Send. |  |
| 61 | Enter again "DL" for the product category to search for and click Send. |  |
| 62 | This time the chatbot doesn't return any search results from the catalogue because the user is only allowed to access products from the Batteries category. Instead, if you enter "MC" as the search term, the bot returns a list of batteries. |  |
With finishing this last exercise you've successfully completed the hands-on lab!