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).
If you're familiar with the SAPCP, one option to make this happen would be specifying/creating a required role for the FLP catalog/group (our app is assigned to the catalog/group) and then assigning the users of your choice to that role manually in the SAPCP. So in our scenario that would mean certain authorizations are assigned on ABAP side (i.e. in SU01/PFCG, maybe for you OData services *Hint Hint*) while the FLP authorizations are assigned on the frontend. Raise your hands if you don't like this approach (I just raised mine)! Wouldn't it be great if we could simply handle the authorization related stuff on our backend, where we have decades of experience with ABAP authorizations as well as well established processes and tools for authorization handling? And then automatically the FLP in the SAPCP knows via telemetry how the authorizations look like? Please raise your hand again if that'S what you want! Oops, telemetry is a little difficult, but here come the magic of the IPS:
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.
Hint: When I say syncing users from ABAP to SAPCP or provisioning of ABAP users to SAPCP it's actually a 1-way direction: changes on ABAP side get reflected on SAPCP, but changes on SAPCP users (i.e. new users or changed roles) do not get synced to ABAP. In fact, at the time of writing the IPS does not support writing authorization objects to SAP NW ABAP (AFAIK this is because NW ABAP doesn't support SCIM). Furthermore, when I say syncing users I should actually say syncing identities or provisioning identities. Got curious and want to learn more about what Identity Provisioning actually means? Google for it or have a look at Identity Provisioning for Dummies (don't take the title personal). Well, and that was a little disclaimer for not being 100% scientifically correct with the terms I use 🙂
Before you continue make sure you've started both your NW ABAP Docker container as well as your SAPCC Docker container (see the previous parts of the blog series). Then login to your SAPCC and create a system mapping by choosing Cloud To On-Premisefrom the left side menu and then clicking the Access Controltab:
The already existing mapping was created in a previous step of the blog series. You can check its connection by pressing the corresponding action button. We could now add the mapping we need manually, or we could simply upload a file containing the configuration for the new mapping (both options are demonstrated in the video). We’ll use the file upload here because is faster, and for exactly that purpose I’ve prepared the following file for you (sapcc_access_control_rfc_only.json😞
The SAPCC understands the JSON file from above. However, we can’t simply upload this as is because SAPCC expects a zip file which contains a JSON file called access_control.json! So let’s fulfill this requirement by creating the right zip file with the following commands (or do in manually):
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!
The IPS will make RFC calls to our ABAP Backend to get the relevant SU01 users etc. This all happens depending on some rules, and we will configure them later. At this point, we want to create a Service User in SU01 on ABAP side. This user will then be used by our IPS (actually it’s the SAPCP destination which we’ll create later as well) to call the white-listed resources of our RFC mapping. As you can see in the video at 08:51, I chose to create the following user:
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”.
Once again having a look at the official IPS documentation you can see that the read-only role SAP_BC_JSF_COMMUNICATION_RO should be everything needed for the IPS to work. Well, that’s not really enough! The service user must have the following Authorization Objects assigned (seems not to be documented for some reason):
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.
Finally, you have to assign the Services User to the role:
For a better demonstration of how IPS works I’ve created a few other roles and the corresponding users as well, for details see video at 14:20:
Additional Roles via PFCG:
Additional Users with assigned Roles from above via SU01:
Later, you’ll see how these users/roles are provisioned to you SAPCP Trial Account.
The IPS allows two types of systems
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).
We can easily generate the credentials by generating so called OAuth Client Credentials in the SAPCP Target System (in our case this will simply be our SAPCP Trial Account), see video at 19:04:
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.
To allow the IPS accessing our NW ABAP running in Docker we have to create an RFC destination pointing exactly to our NW ABAP. In our case, this destination is used by the IPS for accessing our NW ABAP as the Source System (where the users actually come from). Check the video at 20:59 for how to create the RFC destination. For easy Copy & Paste use the following values for the RFC Destination (same as in screenshot below + my Github repo😞
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)!
To allow the IPS accessing our SAPCP account we want to create an HTTP destination pointing exactly to our SAPCP account (i.e. to a trial account). In our case, this destination is used by the IPS for accessing our SAPCP account as the Target System (where the users/identities are actually provisioned to). Check the video at 23:33 for how to create the HTTP destination. For easy Copy & Paste use the following values for the HTTP Destination (same as in screenshot below + my Github repo😞
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).
First we go to the IPS (make sure to enable the IPS if it’s disabled, see screenshots/video):
When getting here initially, you can see you have no Source Systems (and no Target System, no Jobs). I prefer to have the left-side menu open all the time. Now let’s add a Source System by pressing Source Systems before we can press the add button:
Now fill in the relevant values in the Details tab (see the video or the my Github repo😞
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.
In the Properties tab you can add the following two properties:
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!
Now let’s create a Target System with the following configuration (see video at 31:17 and my Github repo😞
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).
In the Properties tab you can add the following two property:
Make sure to press the save button once done!
So now we should have everything ready, let’s check the SAPCP account’s Groups:
Ooooops, it’s empty; there are no Groups! But didn’t we expect a few Groups to be available according to our Source System’s transformation? Yes, but first we have to run the corresponding IPS Read Job! This job can be considered as a “full sync” or “full read”, other prefer to call is the “initial load”. Jobs are always run from the Source System’s Jobs tab by simply pressing the Run Now button (from here you can also schedule the job, i.e. to run it once an hour):
After running the job you can check Job Logs for checking its status (press the Refresh button to see the latest data):
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.
You can verify everything worked as expected by checking your SAPCP account’s Groups once again:
This time you can see we have three Groups, and each of them has one or more users mapped, i.e. the user manager is a member of the Group MyManagerGroup, the Group MyPurchaserGroup currently has two members which are the users manager and purchaser. And as you can see in this example a user can be mapped to multiple groups as well (in our case the manager user in in two Groups). The users come from SU01 in ABAP:
For demonstration purposes, now let’s remove the role ZDEMO_PURCHASER from the user manager in SU01and see what happens:
In order to see a change in the SAPCP account’s Groups we can simply “re-sync” the users by pressing the Run Now button of the Source System’s Resync Job:
After the job has finished our SAPCP Group MyPurchaserGroup does not contain the user manager anymore:
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.
There are multiple ways to achieve what we want, and I’ll show some of them. First, let’s go to the Portal Service and create new Roles:
We’ll add three roles: Manager, SalesRep, Purchaser. After that, we want to assign them to the corresponding groups. This we can achieve by pressing the Assign button right now (in the video I do it this way as an example only for one of the roles):
But we could do it also from the other view (again, in the video you’ll see both options):
From the screenshot above you can tell everybody assigned to the Group MyPurchaserGroup will get Role Purchaser.
Go to your Fiori Configuration Cockpit and create three Catalogs, one for each Role. Then create three Groups, again one for each Role. See the video at 39:40 for all the steps (this post is already to big):
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.
But how do I allow the users to see the FLP app? Well, by assigning the required roles to the user in SU01 on ABAP. You already know how that works, if you don’t then check then continue watching the video. Just like I did in the video, you can invite any of your friends by sharing the link to the FLP. Just make sure to add the User ID of the person you want to invite to SU01. Then give that user let’s say the Manager role in SU01. Finally, resync the job and that’s it. Now ask the user to close the browser and open the link again. Here we go, see the video 🙂
First of all, I’d like to thank you for following all the tutorials, and for waiting so long for this last part; work, the world cup, vacation etc. hit me really hard so I couldn’t make it earlier. I’d also like to thank you for all the comments, contact requests, and private messages here and elsewhere...
Right... actually this should be the conclusion section here:
Most importantly: ABAP is not dead, it’s more alive than ever! And keep in mind, sharing is caring!
Meanwhile, ABAP Trial 7.52 SP01 is out:
Even ABAP in the Cloud is out:
Well, it's not really the Micro Services ABAP kind of thing I anticipated, but that’s the story of another blog series. And that will only happen if SAP adds Community/Trial Versions First to the existing Cloud First strategy 🙂
Cheers, Nabi
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.
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!
- Part 1: ABAP is here and it stays in the DNA of SAP even in the New Age of SAP Development
- Part 2: Installing SAP Cloud Connector into Docker and connecting it to SAP Cloud Platform
- Part 3: Installing SAP NW ABAP into Docker
- Part 4: Configure SAPCC + NW ABAP for Principal Propagation + Docker Network config for both Containers
- Part 5: SAPCC, NW ABAP, SAPCP config for the Identity Provisioning Service to sync users from ABAP to SAPCP
1. Resources
- YouTube: https://www.youtube.com/watch?v=IaDS0kcQnhY
- GitHub: https://github.com/nzamani/sap-cloud-connector-docker/tree/master/ips
2. What will you have at the end of this blog?
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).
If you're familiar with the SAPCP, one option to make this happen would be specifying/creating a required role for the FLP catalog/group (our app is assigned to the catalog/group) and then assigning the users of your choice to that role manually in the SAPCP. So in our scenario that would mean certain authorizations are assigned on ABAP side (i.e. in SU01/PFCG, maybe for you OData services *Hint Hint*) while the FLP authorizations are assigned on the frontend. Raise your hands if you don't like this approach (I just raised mine)! Wouldn't it be great if we could simply handle the authorization related stuff on our backend, where we have decades of experience with ABAP authorizations as well as well established processes and tools for authorization handling? And then automatically the FLP in the SAPCP knows via telemetry how the authorizations look like? Please raise your hand again if that'S what you want! Oops, telemetry is a little difficult, but here come the magic of the IPS:
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.
Hint: When I say syncing users from ABAP to SAPCP or provisioning of ABAP users to SAPCP it's actually a 1-way direction: changes on ABAP side get reflected on SAPCP, but changes on SAPCP users (i.e. new users or changed roles) do not get synced to ABAP. In fact, at the time of writing the IPS does not support writing authorization objects to SAP NW ABAP (AFAIK this is because NW ABAP doesn't support SCIM). Furthermore, when I say syncing users I should actually say syncing identities or provisioning identities. Got curious and want to learn more about what Identity Provisioning actually means? Google for it or have a look at Identity Provisioning for Dummies (don't take the title personal). Well, and that was a little disclaimer for not being 100% scientifically correct with the terms I use 🙂
3. Create an RFC Mapping in the SAPCC
Before you continue make sure you've started both your NW ABAP Docker container as well as your SAPCC Docker container (see the previous parts of the blog series). Then login to your SAPCC and create a system mapping by choosing Cloud To On-Premisefrom the left side menu and then clicking the Access Controltab:
The already existing mapping was created in a previous step of the blog series. You can check its connection by pressing the corresponding action button. We could now add the mapping we need manually, or we could simply upload a file containing the configuration for the new mapping (both options are demonstrated in the video). We’ll use the file upload here because is faster, and for exactly that purpose I’ve prepared the following file for you (sapcc_access_control_rfc_only.json😞
[{
"cloudHost": "nwabap751",
"cloudPort": "sapgw00",
"localHost": "vhcalnplci",
"localPort": "sapgw00",
"protocol": "RFC",
"backendType": "abapSys",
"sncPartnerName": "",
"sapRouter": "",
"authMode": "NONE",
"description": "RFC for SAPCP Identity Provisioning Service",
"allowedClients": [],
"blacklistedUser": [],
"resources": [{
"path": "BAPI_USER",
"enabled": true,
"exactMatchOnly": false,
"description": ""
}, {
"path": "BAPI_USER_GETLIST",
"enabled": true,
"exactMatchOnly": false,
"description": ""
}, {
"path": "BAPI_USER_GET_DETAIL",
"enabled": true,
"exactMatchOnly": false,
"description": ""
}, {
"path": "PRGN_ROLE_GETLIST",
"enabled": true,
"exactMatchOnly": false,
"description": ""
}, {
"path": "PRNG",
"enabled": true,
"exactMatchOnly": false,
"description": ""
}]
}]The SAPCC understands the JSON file from above. However, we can’t simply upload this as is because SAPCC expects a zip file which contains a JSON file called access_control.json! So let’s fulfill this requirement by creating the right zip file with the following commands (or do in manually):
# 1. Download the json file I prepared
wget https://raw.githubusercontent.com/nzamani/sap-cloud-connector-docker/ master/ips/sapcc_access_control_rfc_only.json
# 2. Rename the downloaded file
mv sapcc_access_control_rfc_only.json access_control.json
# 3. Put it into a zip file
zip access_control.zip access_control.json
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!
4. Creating a Service User on ABAP Backend (SU01) used by the IPS
The IPS will make RFC calls to our ABAP Backend to get the relevant SU01 users etc. This all happens depending on some rules, and we will configure them later. At this point, we want to create a Service User in SU01 on ABAP side. This user will then be used by our IPS (actually it’s the SAPCP destination which we’ll create later as well) to call the white-listed resources of our RFC mapping. As you can see in the video at 08:51, I chose to create the following user:
- User ID: ZSSAPCPIPS
- Password: Appl1ance
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.
5. Creating a Service User on ABAP Backend (SU01) used by the IPS
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”.
6. Creating a new ABAP Role containing some required Authorization Objects
Once again having a look at the official IPS documentation you can see that the read-only role SAP_BC_JSF_COMMUNICATION_RO should be everything needed for the IPS to work. Well, that’s not really enough! The service user must have the following Authorization Objects assigned (seems not to be documented for some reason):
- S_RFC
needed because the IPS will call RFCs, thus the service user needs RFC authorization
- RFC_TYPE: Function group, Function Module
- RFC_NAME
- BAPI_USER
- BAPI_USER_GETLIST
- BAPI_USER_GET_DETAIL
- PRGN_ROLE_GETLIST
- PRNG
- ACTVT: Execute
- S_USER_AGR
needed because the function module PRGN_ROLE_GETLIST checks for it
- ACT_GROUP: DUMMY
- ACTVT: Display
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.
Finally, you have to assign the Services User to the role:
7. Creating Demo Users with Demo Roles (ABAP)
For a better demonstration of how IPS works I’ve created a few other roles and the corresponding users as well, for details see video at 14:20:
Additional Roles via PFCG:
- ZDEMO_MANAGER
- ZDEMO_PURCHASER
- ZDEMO_SALESREP
Additional Users with assigned Roles from above via SU01:
- SALESREP
- Roles: ZDEMO_SALESREP
- PURCHASER
- Roles: ZDEMO_PURCHASER
- MANAGER
- Roles: ZDEMO_MANAGER, ZDEMO_PURCHASER
Later, you’ll see how these users/roles are provisioned to you SAPCP Trial Account.
8. Generate OAuth Client Credentials in Target SAPCP account
The IPS allows two types of systems
- Source Systems
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. - Target Systems
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).
We can easily generate the credentials by generating so called OAuth Client Credentials in the SAPCP Target System (in our case this will simply be our SAPCP Trial Account), see video at 19:04:
- Go to Security-> OAuth-> Platform API and press Create API Client
- checkAuthorization Management (will add Read Authorization and Manage Authorization automatically)
- press “save”
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.
9. Create an RFC Destination in your SAPCP account
To allow the IPS accessing our NW ABAP running in Docker we have to create an RFC destination pointing exactly to our NW ABAP. In our case, this destination is used by the IPS for accessing our NW ABAP as the Source System (where the users actually come from). Check the video at 20:59 for how to create the RFC destination. For easy Copy & Paste use the following values for the RFC Destination (same as in screenshot below + my Github repo😞
- Name: IPS_SOURCE_NPL_001_RFC
- Type: RFC
- Description: IPS Read from NPL in Docker (NW ABAP Trial)
- Location ID:
- User: ZSSAPCPIPS
- Password: Appl1ance
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)!
10. Create an HTTP Destination in your SAPCP account
To allow the IPS accessing our SAPCP account we want to create an HTTP destination pointing exactly to our SAPCP account (i.e. to a trial account). In our case, this destination is used by the IPS for accessing our SAPCP account as the Target System (where the users/identities are actually provisioned to). Check the video at 23:33 for how to create the HTTP destination. For easy Copy & Paste use the following values for the HTTP Destination (same as in screenshot below + my Github repo😞
- Name: IPS_TARGET_MYTRIAL_SAPCP
- Type: HTTP
- Description: IPS Target to My SAPCP Trial
- URL: https://api.hanatrial.ondemand.com/authorization/v1/accounts/p123456trial
- User: Client ID
- Password: Client Password
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.
11. Add a Source System to your SAPCP IPS
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).
First we go to the IPS (make sure to enable the IPS if it’s disabled, see screenshots/video):
When getting here initially, you can see you have no Source Systems (and no Target System, no Jobs). I prefer to have the left-side menu open all the time. Now let’s add a Source System by pressing Source Systems before we can press the add button:
Now fill in the relevant values in the Details tab (see the video or the my Github repo😞
- Type: SAP Application Server ABAP
- System-Name: NW-ABAP-751-NPL
- Destination Name: IPS_SOURCE_NPL_001_RFC
- Description: NW ABAP 7.51 Trial in Docker
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.
In the Properties tab you can add the following two properties:
- role.filter: ^(YDEMO|ZDEMO).*
- trace.failed.entity.content: true
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!
12. Add a Target System to your SAPCP IPS
Now let’s create a Target System with the following configuration (see video at 31:17 and my Github repo😞
- Type: SAP Cloud Platform Java/HTML5 App
- System Name: SAPCP-MyTrial
- Destination Name: IPS_TARGET_MYTRIAL_SAPCP
- Description: Trial SAPCP Account
- Source System: NW-ABAP-751-NPL
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).
In the Properties tab you can add the following two property:
- trace.failed.entity.content: true
Make sure to press the save button once done!
13. Run the Read job from the Source System inside your SAPCP IPS
So now we should have everything ready, let’s check the SAPCP account’s Groups:
Ooooops, it’s empty; there are no Groups! But didn’t we expect a few Groups to be available according to our Source System’s transformation? Yes, but first we have to run the corresponding IPS Read Job! This job can be considered as a “full sync” or “full read”, other prefer to call is the “initial load”. Jobs are always run from the Source System’s Jobs tab by simply pressing the Run Now button (from here you can also schedule the job, i.e. to run it once an hour):
After running the job you can check Job Logs for checking its status (press the Refresh button to see the latest data):
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.
You can verify everything worked as expected by checking your SAPCP account’s Groups once again:
This time you can see we have three Groups, and each of them has one or more users mapped, i.e. the user manager is a member of the Group MyManagerGroup, the Group MyPurchaserGroup currently has two members which are the users manager and purchaser. And as you can see in this example a user can be mapped to multiple groups as well (in our case the manager user in in two Groups). The users come from SU01 in ABAP:
For demonstration purposes, now let’s remove the role ZDEMO_PURCHASER from the user manager in SU01and see what happens:
In order to see a change in the SAPCP account’s Groups we can simply “re-sync” the users by pressing the Run Now button of the Source System’s Resync Job:
After the job has finished our SAPCP Group MyPurchaserGroup does not contain the user manager anymore:
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.
14. Create SAPCP Roles and assign them to SAPCP Groups
There are multiple ways to achieve what we want, and I’ll show some of them. First, let’s go to the Portal Service and create new Roles:
We’ll add three roles: Manager, SalesRep, Purchaser. After that, we want to assign them to the corresponding groups. This we can achieve by pressing the Assign button right now (in the video I do it this way as an example only for one of the roles):
But we could do it also from the other view (again, in the video you’ll see both options):
From the screenshot above you can tell everybody assigned to the Group MyPurchaserGroup will get Role Purchaser.
15. Assigning Roles to SAPCP FLP Catalogs and Groups
Go to your Fiori Configuration Cockpit and create three Catalogs, one for each Role. Then create three Groups, again one for each Role. See the video at 39:40 for all the steps (this post is already to big):
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.
But how do I allow the users to see the FLP app? Well, by assigning the required roles to the user in SU01 on ABAP. You already know how that works, if you don’t then check then continue watching the video. Just like I did in the video, you can invite any of your friends by sharing the link to the FLP. Just make sure to add the User ID of the person you want to invite to SU01. Then give that user let’s say the Manager role in SU01. Finally, resync the job and that’s it. Now ask the user to close the browser and open the link again. Here we go, see the video 🙂
16. Conclusion
First of all, I’d like to thank you for following all the tutorials, and for waiting so long for this last part; work, the world cup, vacation etc. hit me really hard so I couldn’t make it earlier. I’d also like to thank you for all the comments, contact requests, and private messages here and elsewhere...
Right... actually this should be the conclusion section here:
- In the whole series we’ve seen several technologies in action
- The On-Premise SAP stuff works just fine with the SAP Cloud Platform
- Your users can stay where they are: behind your firewall, i.e. in your NW ABAP!
- You can still keep your existing Authorization Management tools and processes
- The SAPCC and IPS can be key for your companies cloud strategy going hand in hand with you On-Premise "strategy"
- …
Most importantly: ABAP is not dead, it’s more alive than ever! And keep in mind, sharing is caring!
Meanwhile, ABAP Trial 7.52 SP01 is out:
- AS ABAP 752 SP01, developer edition, to download
- AS ABAP 7.52 SP01, developer edition: Concise installation guide
- AS ABAP 7.5x : ASE License available
Even ABAP in the Cloud is out:
Well, it's not really the Micro Services ABAP kind of thing I anticipated, but that’s the story of another blog series. And that will only happen if SAP adds Community/Trial Versions First to the existing Cloud First strategy 🙂
Cheers, Nabi
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.
- SAP Managed Tags:
3 Comments
