1. Resources YouTube: https://www.youtube.com/watch?v=H0GEg8r7P48 GitHub: https://github.com/nzamani/sap-cloud-connector-docker 2. What will you have at the end of this blog? So far, both our NW ABAP Trial and SAPCC are pretty naked; there is not much of configuration (yes, I know the NW ABAP Trial is actually well configured out of the box). In this blog we’ll start with configuring an HTTPS connection from your SAPCC to your NW ABAP. Later, this connection (a so called system mapping in the SAPCC) will be used when our apps running on the SAPCP call OData services implemented on our NW ABAP. When checking the connection from the SAPCC web UI we’ll see that for some reason the SAPCC cannot reach our NW ABAP. We’ll have to fix this by putting both Docker containers onto the same Docker Network. For a better understanding, this is like putting two physical machines onto the same local network using a cable so that they can reach each other. Part of the configuration is also to provide certificates which are then configured on both the SAPCC and NW ABAP. You’ll see how to generate the needed certificates using OpenSSL and how to configure both SAPCC and NW ABAP to use/trust them. After a few other configuration steps on NW ABAP you’ll see how to create a so called destination on the SAPCP which basically connects to your NW ABAP through the SAPCC. In fact, we’ll create two destinations to illustrate the differences, one with Principal Propagation and the other one with Basic Authentication. For testing purposes we’ll use the SAP Web IDE to generate a simple good old fashioned Master Detail app using the SAP Fiori Master-Detail Application template. During the template wizard steps you’ll be asked to choose an OData service, which we will do by choosing the good old GWSAMPLE_BASIC service available on your own NW ABAP. Before you can select that service you’ll have to choose a system (basically the created destination) which is then used by the SAP Web IDE to call the Catalog Service of our NW ABAP (SAP Gateway) in order to list all available services. This call, of course, only works if the calling user (your user) is somehow authenticated on NW ABAP side; and that’s exactly the magic we want to see working. After finishing the Master-Detail template wizard steps you’ll see how easy it is to run the application from within your SAP Web IDE. As a final step, you’ll also see how to create a simple Fiori Launchpad (FLP) in the SAPCP Portal Service and how to add our little application to that launchpad. After this you can call our app from a real FLP. And when you do this, the app opens up, calls the OData service on your NW ABAP using the destination you created in your SAPCP account, and displays all the data. The image above show exactly what your will have in the end of this blog (except we’ll only create one FLP app). Please pay attention that both your NW ABAP and SAPCC are running on your own machine, while the SAPCP is not Also, when you use your browser to open your app in the SAPCP it means your browser connects to SAPCP, and from there the SAPCP thanks to some magic knows how to connect to your local NW ABAP. Also note that the image shows two different user stores! Make sure to read the conclusion below! 3. What is Principal Propagation and why do I need it? SAPCP, the Portal Service, the SAPCC, and an On-Premise NW ABAP (the latter two we run in our own Docker containers): Let’s assume you have created an FLP using the Portal Service of your SAP Cloud Platform’s account (you’ll see how that works in the video). After this you configure your FLP (Apps, Catalogs, Groups, Roles). Most probably some of your apps will communicate to your NW ABAP backend using OData via destinations configured in your SAPCP account. Requests going through the destinations will then be piped through the SAPCC which in turn manages the calls to the real ABAP OData “Endpoint” (SAP Gateway). In a typical scenario you want to make sure that only authorized users can access your apps in the FLP, and thus they need to be authenticated somehow. Often you simply delegate the authentication process via SAML 2.0 to an Identity Provider (IdP), i.e. by using SAPCP Identity Authentication service – in short Identity Authentication (IdA). This is how things work (simplified): A user opens the FLP or an app inside the FLP in the browser Browser gets redirected to SAPCP Identity Authentication service User authenticates there Browser gets redirected back to app with some sort of a token (details skipped on purpose). At this point the user is authenticated on the SAPCP; thus you can see your name in your FLP. In case you have directly called an app (i.e. via bookmark) or when clicking an app on your FLP: The app calls an OData service implemented on your NW ABAP backend. In fact, the browser thinks the OData service is an HTTP call going to the SAPCP (account) while it’s actually a call to a so called destination which which forwards/proxies the original call to the SAPCC. The SAPCC receives the OData call and the user context of authenticated user (on SAPCP passed over by the destination). Taking this user context the SAPCC creates a short lived X.509 certificate and signs it (Kerberos is possible as well). Then the SAPCC forwards/multiplexes the HTTPS OData call together with the certificate to the right NW ABAP backend. The certificate is created for the user that calls the OData service from the SAPCP FLP. It serves for the authentication on ABAP side! That’s basically what we mean when we say the SAPCC handles Principal Propagation to the ABAP backend. NW ABAP validates the certificate and checks that the user who calls the OData service does really exist in ABAP’s user store (SU01). If the user exists there will also be some authorization checks done behind the scenes, but let’s forget this for now… Finally, the OData service gets executed. If your UserID on SAPCP was P1234567 then sy-uname inside the SAP GW OData service implementation (ABAP) will be P1234567 as well! Voila – how cool is that? Then the OData response is returned back the whole path up to the caller (= our app running in an SAPCP FLP) Reconsidering the steps above, we can say that for our scenario Principal Propagation means that the user who got authenticated on the SAPCP is recognized on NW ABAP! It’s important to note that the user must already be available in the ABAP user store (SU01) together will all the needed authorizations before the OData call happens, else NW ABAP will deny the request with an HTTP 401 response and the user will see a Basic Authentication dialog! In other words: Principal Propagation does not create users on ABAP side! This explanation should tell you that thanks to the SAPCC it’s quite easy to use your existing ABAP backend in the cloud! Your authorization checks on ABAP side still work just fine, even though the user got actually authenticated on SAPCP side! Awesome, isn’t it? Now let’s start to configure our SAPCC by setting up the System Mappings. 4. Creating System Mappings for OData in SAPCC The screenshot above is from the video (4:32) and shows you the result of our first system mapping. It connects a virtual host to an internal host. The virtual host is what you will see in the SAPCP later when we create so called destinations. The internal host is (in our case) a real NW ABAP running inside our Docker container. As you can see from the screenshot above we’re using the same hostname we used for our NW ABAP Docker container. It’s quite easy to create a system mapping, please have a look into the video. After creating a a system mapping you cold check the connectivity by pressing the corresponding action button. For some reason our SAPCC which runs inside a Docker container cannot reach our NW ABAP. Let’s fix this next. 5. Putting the NW ABAP and SAPCC containers onto the same Docker Network Our SAPCC does not find the ABAP host vhcalnplci. This is because the two containers are not on the same network yet. Let’s change this with the following Docker commands: # 1. Creating a Network called saptrial docker network create -d bridge saptrial # 2. Connect Container sapcc to Network saptrial + make sapcc available via alias mysapcc docker network connect --alias mysapcc saptrial sapcc # 3. Putting an existing NW ABAP Container onto the same Network (with different aliases) docker network connect --alias vhcalnplci saptrial nwabap751 docker network connect --alias vhcalnplci.dummy.nodomain saptrial nwabap751 The first command creates a Docker Network called saptrial. The second command puts the sapcc container onto the Network saptrial and makes it available under the alias mysapcc (as you remember that’s also the hostname of our sapcc container). Finally, we put our nwabap751 container onto the same Docker Network saptrial and and use the alias vhcalnplci (the hostname of our ABAP container). After the first three commands we can re-check the connectivity of our system mapping. And guess what, everything is green this time (see screenshot below). The connection to NW ABAP seems to be fine, but no resources are accessible yet. In other words, although the system mapping works our OData services cannot be reached yet because they are not whitelisted in the SAPCC for our system mapping. Check the video to see how easy it is to make resources available, but keep in mind that we chose “/” as the URL Path because we are a little lazy (in prod you would often rather choose exactly what you want to publish). After this we continue by clicking on the Principal Propagation tab in order to configure which SAPCP IdPs or apps acting as IdP we want trust. This is a low-brainer, please check the video (6:15) for details: 6. Generating certificates needed for Principal Propagation In order to make Principal Propagation to work we need to have the right certificates. We’ll simply generate them on our own using OpenSSL (make sure you have installed OpenSSL). # optional: create a folder and switch into it mkdir mycerts && cd mycerts # download my prepared ca.conf file (check the comments I left on github fo some details) wget https://raw.githubusercontent.com/nzamani/sap-cloud-connector-docker/master/certs/ca.conf # now let's work a little with OpenSSL: openssl genrsa -des3 -out SAPCC_CA.key 1024 # ==> pass phrase for Root_CA.key, i.e.: sapcc openssl req -sha256 -new -x509 -days 9999 -key SAPCC_CA.key -out SAPCC_CA.crt #==> Choose what ever you want, i.e.: # Country Name (2 letter code) []:DE # State or Province Name (full name) []:BW # Locality Name (eg, city) []:NPL # Organization Name (eg, company) []:SAPCC # Organizational Unit Name (eg, section) []:SAPCC # Common Name (eg, fully qualified host name) []:mysapcc # Email Address []: openssl pkcs12 -export -clcerts -in SAPCC_CA.crt -inkey SAPCC_CA.key -out SAPCC_CA.p12 #==> type the password "sapcc" three times (same as above) # now intermediate cert: touch certindex echo 1000 > certserial echo 1000 > crlnumber # now hit: openssl genrsa -out intermediate.key 1024 openssl req -new -sha256 -key intermediate.key -out intermediate.csr openssl ca -batch -config ca.conf -notext -in intermediate.csr -out intermediate.crt openssl pkcs12 -export -clcerts -in intermediate.crt -inkey intermediate.key -out intermediate.p12 This will generate a bunch of files for you, but we only need the files intermediate.p12 for our SAPCC and SAPCC_CA.crt for our SAP NW ABAP. 7. Certificate and Principal Propagation configuration on SAPCC After having the certificates generated we want to use the generated intermediate certificate intermediate.p12 for our SAPCC. Choose Configuration on the left-side pane and then clock on the tab ON PREMISE. At 10:26 in the video you can see how to upload that one certificate to your SAPCC in order to use it both as your System Certificate and CA Certificate (this takes only a few seconds). We’re done with SAPCC for now, but we’ll come back later to that screen in order to create a sample certificate which we will user on ABAP side (discussed later). So keep your SACC container running and don’t close your browser… 8. Certificate and Principal Propagation configuration on NW ABAP Now let’S start the NW ABAP configuration with transaction STRUST. We fire it up because we want to tell NW ABAP to trust the generated CA certificate SAPCC_CA.crt. Simply import the file and afterwards add the certificate to the certificate list by pressing the corresponding button. For all the details follow the video at 11:30. Don’t forget switch to save when done! After this step you wanna go to transaction RZ10 because you need to change a few profile parameters. The configuration allows us to define what certificates will actually be trusted based on the Subject and Issuer. Before you Continue: It seems that you have to import the profiles from active servers before you continue. This took me a while to find out, I think I killed about 10 Docker containers this way including all the configuration about. If you don’t do this (see video for details) then your NW ABAP will suddenly fail to start (i.e. inside you container). There are ways to fix that, the best starting point would be to check the log files. However, if you choose Utilities -> Import profiles -> Of active servers in transaction RZ10 before you continue then you should be just fine: Now we continue and choose (in our case) the profile NPL_D00_VHCALNPLCI and add the following profile parameters: 1. icm/HTTPS/trust_client_with_issuer Value: CN=mysapcc, OU=SAPCC, O=SAPCC, L=NPL, SP=BW, C=DE 2. icm/HTTPS/trust_client_with_subject Value: OU=SAPCC, O=SAPCC, C=DE, SP=BW, CN=mysapcc 3.login/certificate_mapping_rulebased Value: 1 The values for the first two can be copied from the SAPCC, see the video for details. The third parameter allows us to automatically map SAPCP users to ABAP users. Then go to transaction RZ11. you find the following parameters with the following values: 1. icm/HTTPS/verify_client Value should already be 1 2. login/certificate_mapping_rulebased: Change the value from 0 to 1 The changes made via RZ11 will be active immediately without having to restart the server. For the parameters we changed via RZ10 we need to go to transaction SMICM and restart the server from the menu: In order to verify the parameters we changed via RZ10 are really active you can simply check the parameters: Now you wanna go to transaction SU01 and add a user. In our demo, the User ID must be the same as the one you use on the SAPCP. In case you are using a trial account it’s most probably something like P123456 (no “trial” at the end), but it could be a C/D/I/S-User as well… Make sure to give that user SAP_ALL; that’s only to speed up with the demo, in production you would not do that! Now go to transaction code CERTRULE. Here we can make sure the SAPCP users are mapped correctly to the ABAP users. For this step, first we go back to the SAPCC and create a sample certificate. Finally we can upload this sample certificate file in CERTRULE and do some configuration (see video). In case you missed something: the video contains all the details! 9. Creating destinations on SAPCP Please follow the instructions or watch the video to create two destinations. Once you created the destinations make sure to check the connection: If you see the success message it means your Docker containers running on localhost are now attached to the SAPCP. 10. Creating a Master Detail Fiori/UI5 app via SAP Web IDE which calls an NW ABAP OData Service To verify everything really works open your SAP Web IDE (Full-Stack is finally enabled per default). Once the WebIDE shows up create a new project from template, then choose SAP Fiori Master-Detail Application (or what ever template you prefer to test with): When you’re asked for the data connection you can basically choose one of the destinations we created; make sure to choose the one with Principal Propagation: Now the WebIDE will call the Catalog Service of your SAPGW / NW ABAP, and you should see a list of available OData Services: We will simply use the good old GWSAMPLE_BASIC service. But wait… We didn’t have to enter any credentials, right? Isn’t that magic? You’ve just experienced Principal Propagation. Once you’ve finished the template steps you can run your app from within your SAP Web IDE, i.e. using the FLP Sandbox: This is real data coming from YOUR own NW ABAP! And you’re getting the data without being asked to enter any credentials because Principal Propagation just worked! In case you don’t see any data you might have to generate some sample data; see the video for details. 11. Creating a SAPCP Fiori Launchpad and adding the app Well, we don’t want to run productive apps from the Web IDE, right? So why not creating an FLP on SAPCP using the Portal Service and then putting our little app into that FLP? The process takes not even 3 minutes! If you follow the steps in the video you’ll have a real FLP on SAPCP: And the best part is that you can share the link to your FLP with your friends and they can call your apps as well! The only thing you have to take care of is creating a corresponding user on your NW ABAP in SU01, and that user must be the same as the one used to logon via SAP Authentication Service (aka SAP ID). This basically means your friends need a user on SAPCP (which is free). But be aware not to sign any SLAs, because anytime you stop your SAPCC or ABAP Docker container your apps can’t reach their backend. 12. Conclusion and Outlook You don’t like cloud because your data has to be in the cloud? Well, not so true as you might know by now. This demonstration clearly illustrates that the data is and stays on-premise! If you stop the SAPCC then your data is not available via SAPCP anymore! Your data is piped through SAPCP infrastructure(s) at runtime, i.e. anytime a user opens an app in your FLP which calls an OData service on your backend (via destinations + SAPCC). I guess you have to trust that SAP and their infrastructure partners (Google, Amazon, Microsoft,…) don’t do some kind of “deep inspection” of the data piped through their infrastructure (for whatever reason). But be aware that cloud providers are monitoring companies, that means they need and have tools for monitoring to make sure the cloud is up and running as good as possible (I hope they don’t monitor clear text passwords in log files…). But hey, don’t we trust the internet and the internet providers? I should better stop to elaborate here too much. However, if you ask me, I don’t think cloud providers want to kill their cloud business and thus I do have lots of trust – at least for SAP (not so sure about Google…). Back to the topic… So far Principal Propagation works just fine. As you know your user data is on ABAP side (neglecting the SAPCP user). We have an FLP on SAPCP, but how can we configure the authorizations for seeing certain apps in the FLP? We could do that on SAPCP side. However, we have an ABAP server, and we want it to be our main user store. Furthermore, let’s assume we have all ABAP roles, processes, and tools etc. to create users on ABAP and assign them there the needed authorization. Wouldn’t it be cool to somehow sync the users to the SAPCP so that based on the ABAP users and authorizations the SAPCP FLP knows what apps to show? That’s exactly the topic for the next and last blog of the series. And the key is the SAPCP Identity Provisioning service. Seeing this in action really feels like magic! So stay tuned, but give me some time to watch the World Cup.