In the last two parts of the blog series you've installed both an SAP Cloud Connector (SAPCC) and a NW ABAP 7.51 SP02 Trial into Docker running on your own machine. After having connected your two Docker containers you've also learned how to configure everything to get Principal Propagation to work. We've validated that Principal Propagation works by creating a simple Fiori Launchpad (FLP) using the Portal Service of our own trial account on the SAP Cloud Platform (SAPCP). Inside that FLP we deployed a simple UI5 application which we generated using the SAP Web IDE. This little application calls an OData service on our NW ABAP running inside our Docker container on localhost. Isn't it cool that your UI5 app deployed to the SAPCP accesses your own laptop for the business logic implemented inside NW ABAP?
However, there is one issue: everyone who accesses our SAPCP FLP will see our little UI5 app. We want to change this by assigning certain roles to users in SU01 of our NW ABAP which authorizes them to see our UI5 app in the SAPCP FLP. But wait… How the heck do the ABAP roles get into the SAPCP in a way that the SAPCP FLP understands what apps to display for a certain authenticated user? The SAPCP Identity Provisioning Service (IPS) handles the magic for us and in this blog you'll learn how to setup everything. Both as an ABAP and SAPCP developer you're going to love the IPS. For me it's one of the most important SAPCP services available and you're going to see how things are wired together!
Having read the previous parts, you should see the difference of the image above compared to the image of the last part of this blog series. So far, the users access our app which is deployed to the FLP. Everyone who has the link to our FLP can access the FLP after SAML authentication thanks to the SAPCP Authentication service. We didn't have to do much for that, it just worked out of the box; per default the SAP ID Service is a trusted Identity Provider (of course that's customizable, but that's worth another tutorial).
The SAPCP has its own user store which includes users, groups, and roles. Every time a new user authenticates and accesses your SAPCP account a basic user record gets created in your SAPCP's account user store containing the UserID. You can also create users manually using the SAPCP Cockpit. This user store can be used by the different SAPCP services, i.e. by the Portal Service in order to decide what apps a user can see; well, more accurately: which catalogs/groups a user can see, while apps can be assigned to multiple catalogs/groups. In other words: if a certain user has the authorization for a certain FLP catalog/group then the user is allowed to see/access the contained apps.
Our goal is to change the default behavior. In other words, while any authenticated user should be able to access our FLP, only those of them with the right authorization should be able to see our little app on the FLP. Don't mix this with backend authorization, i.e. for the OData services – in your OData services you'll still have to check the authorizations at runtime, else you might have a security issue (out of scope in this blog).
The IPS is basically basically a Java based SAPCP service which gets users from a given source system according to own rules and writes them to a configured target system, again according to own rules. In our case, the source system is NW ABAP, while our target system is our own SAPCP trial account. More precisely, in our showcase the IPS reads our users from the SU01 of our NW ABAP running in Docker (source system) according to rules which we want to define. Then, these users are written to our SAPCP trial account (target system) according to another set of rules which we define. Both the source system and target system will have an own destination in the SAPCP: for reading the users/roles from SU01 the IPS will use an RFC connection, while for writing the user identities to the SAPCP user store an HTTP destination is used. The good thing is that the IPS does not have to be triggered manually each time a new user was created in the SU01. Instead, we can configure it to run the sync as a job, i.e. let's say very 15 minutes (if you want).
I've just mentioned several strange terms without explaining why: sync, user, role, group. When talking to colleagues, I typically say the IPS is syncing the users from SU01 to the SAPCP. The techie word for that is Provisioning. All that happens based on rules we can define, i.e. "Get all users having a role starting with ZMANAGER* and assign them to the SAPCP group called Manager". Using this approach, we can simply assign all needed SAPCP roles to the group manually in the SAPCP Cockpit, while everyone assigned to the group will get all the contained roles.
All you should have understood so far is by using the IPS we can manage all User authorizations on ABAP, i.e. changes in SU01 get reflected in the SACP user store. In case I've lost you please make sure to watch the video a few times. I gave my best to add lots of details. Now let's start with the work.
Finally, we can press the upload button (see screenshot above) and choose the zip file we just created for the upload. Upon successful upload, a new RFC mapping is created and visible in the list of mappings. Now it's the right time to check its connection by pressing the corresponding action icon/button; this should return the check result "Reachable" which means the RFC connection to your ABAP system is fine. When selecting the created mapping you will recognize that the mapping makes five "prefix" resources accessible (all others not matching are blocked). You can consider this as a white list of resources (here RFC connections) that the SAPCC allows to call – important feature, isn't it?!
But why does the list of accessible resources show three green squares while two are black RAUTE? Well, that's because the prefix BAPI_USER already covers the other two items starting with BAPI_USER*. No worries – this should not cause any issues. Furthermore, having exactly these five items is what the official documentations asks us to do. From the screenshot above you can also tell that the order of the accessible resources seems to matter (at least for the calculation of the status column) because both items starting with PRNG have green squares.
You could have created the RFC mapping and configure the accessible resources manually from the SAPCC UI as well. In fact, this is covered my video as well, and if you follow the video carefully you'll learn about a trial restriction: with your SAPCP trial account only two active mapping are allowed! In case you try to add a third (active) mapping the SAPCC will show you a corresponding error message. Attention: when this message gets displayed your SAPCC gets disconnected from the your SAPCP Trial account! So, make sure to reconnect your SAPCC; for details see the video at 05:45.
You may want to have a look at the excellent documentation of SAPCP Identity Provisioning Service on SAP HELPfor additional details; it served great for me!
Make sure to assign an initial password! Don't worry about having to reset the password after the first login; Service Users don't have to reset password after the first logon.
Hint: ABAPers often use the term Technical User as a synonym for Service User.
The Service User we just created needs some authorizations, otherwise the IPS will fail to do its job. According to the official IPS documentation the following read-only role is everything needed: SAP_BC_JSF_COMMUNICATION_RO. This Role must be assigned to our Service User, i.e. by using the Transaction PFCG. The video at 10:10 illustrates exactly what to do, and it even shows you how to activate the profile etc and how to make sure everything is "green".
We'll create a new Role containing the mentioned Authorization Objects. The role must then be assigned to the Service User, and that's it. The video at 11:25 illustrates everything in detail. First, you go to Transaction PFCG and create a role, i.e. ZS_RFC_SAPCPIPS. Then you assign the mentioned Authorization Objects with the values mentioned above.
Later, you'll see how these users/roles are provisioned to you SAPCP Trial Account.
From where the users/roles etc. are read by the IPS. This is where your users come from. In our case, our Source System is our NW ABAP running in Docker on localhost.
Where everything gets provisioned to. In our case, the Target System in an SAPCP Account.
In other words: we want to get our users from ABAP provisioned into our SAPCP account.
My own SAPCP account's IPS can provision users to any SAPCP account, i.e. to yours, or even to the very same SAPCP account to which the IPS belongs. In our case, the IPS can be considered as a client that wants to access some (Authorization Management) APIs of a given SAPCP account, and thus we need credentials so that the IPS can call the APIs using a given user id with the needed authorization together with a password ("secret).
Important: Make sure to save the generated OAuth Client Credentials (both Client ID and Client Secret, the latter one cannot be retrieved later)!!!
We will use the credentials when we create an HTTP Destination (see below). The IPS will access the SAPCP Target System using this destination and its configured credentials.
The User is the Service User we created on ABAP side using SU01. It has all authorizations needed by the IPS to operate successfully. Make sure to set properties for the destination as well (see screenshot)!
The values for User and Password are the OAuth Client Credentials we created above. Make sure to set properties for the destination as well (see screenshot)!
ATTENTION: Back then when I created the video the URL used for OAuth2TokenServiceURL was different (see video at 25:51). SAP has chosen to change this slightly, and that initially broke lots of configurations because the old URLs (without the "api") simply returned an HTTP 302, but the IPS could not handle that. There was not even a single note ahead of this change. In fact, I had several productive configurations for different customers, and suddenly nothing worked anymore. The values above are the correct ones, the values in the video are outdated (see video at 25:51). Make always sure to be in sync with the official docs.
Finally, it's time to start configuring the IPS itself by creating both a Source System and a Target System. First, we'll create a Source System (see video at 26:17).
Since our Source System for the users is an NW ABAP we choose SAP Application Server ABAP for Type. As you can. guess, the Destination Name references the Destination we created earlier (IPS_SOURCE_NPL_001_RFC).
In the Transformation tab you can simply enter the content of the JSON file I prepared for you (see video for details). Basically, this configuration file tells the IPS to map users with certain ABAP roles to a corresponding SAPCP group. For example, users having the ABAP role ZDEMO_MANAGER will be mapped to the SAPCP group MyManagerGroup. But why groups? Well, in SAPCP you can create Groups and assign Roles to these Groups. In the end, users being part of a given Group will get all Roles assigned to the group. This approach can save time to maintain roles, and I'm sure you'll learn to love that approach.
The property abap.role.filter makes sure that only users with ABAP roles starting with YDEMO or ZDEMO will be considered by the IPS. The other property adds details to the logs (feel free to set it to false).
Don't forget to hit the save button!
Since our Target System is an SAPCP account we choose SAP Cloud Platform Java/HTML5 App for Type. As you can. guess, the Destination Name references the Destination we created earlier: IPS_TARGET_MYTRIAL_SAPCP. It points to the SAPCP account to which the IPS will write data to (in fact, where the IPS will make changes). We select the Source System NW-ABAP-751-NPL, which is the one we just created in the previous step.
In the Transformation tab you can simply enter the content of another JSON file I prepared for you (see video for details). Basically, this configuration tells the IPS how to create the Group and who will be assigned to it. For a better understanding you can say the tansformation of the Source System decides what entities to select from the Source System (= NW ABAP in our case), while the transformation of the Target System tells how the found items and data passed over from the Source System will be handled/created on SAPCP side (= Target System in our case).
Make sure to press the save button once done!
Once the job is done you can check the details by selecting the corresponding row in the table. In our case we can see that three entities of type group were read (I prefer to say "calculated") from the Source System, while (these) three entities of type group were created in the Target System.
Isn't this amazing? This tells us we can do all our authorization management stuff in our central user store – in our case on ABAP side! How cool is that? And that's not all, because next we want to use this approach for assigning SAPCP roles (to the SAPCP Groups) used by the SAPCP FLP! In other words: as you can see in the screenshot above the roles table is empty; let's create SAPCP roles and add them to our SAPCP Groups.
From the screenshot above you can tell everybody assigned to the Group MyPurchaserGroup will get Role Purchaser.
The Catalogs and Groups are currently empty. Make sure to add one or more apps now. In the video I chose to add the Manage Products UI5 app, and I assigned it to both the Manager Catalog and Group (see video for details).
Once you're done publish your site as mentioned on the video. After opening your FLP you can see the app. But why can you see the app? Does you user have the Manager suddenly? Nope. The reason is simple: it's your SAPCP trial account, you are the admin, and as such you can see all the apps. In the video you can see I verify what I just claimed by signing in with a different user, and guess what: the app that shall be visible only to the Manager (Manage Products) is not visible in the SAPCP FLP anymore.
Your users can stay where they are: behind your firewall, i.e. in your NW ABAP!
Most importantly: ABAP is not dead, it's more alive than ever! And keep in mind, sharing is caring!
ps sorry fo that last huge part of the series. I agree it's way to big for only one post, and that doesn't make the quality better.
wow, excellent blog post, what an effort!
Or am I reading wth wrong here?
You are correct, this feature was published recently on Sept 17th 2018.
Thanks for your blog! I'm a newbie at CP, this was very helpful.
I still have a question. In our case the users need access (via CP) to the mobile service to call the OData services implemented on ABAP backend, When we do a sync with only the users , we see that they are created in the log , but i can't find them in the CP. When we sync the abap roles, we can see the users in the SAPCP account's Groups. In the backend we have so many roles, we don't want them all in de CP. Can we only use the users, or do we have to sync the roles? How do we give the users access to the mobile service? and how can they logon to the CP? that's isn't clear to me. There is a lot of information/blogs about this, but i can't find the right answer for our case. Hope you can help me.