This blog is part of a series of tutorials explaining the usage of SAP Cloud Platform Backend service in detail.
In the beginning of our series, we learned the initial configuration, required to get us up to speed.
That was:
Configure our Trial account to get access to the SAP Cloud Platform Backend service
Configure the roles which a user (our user) needs in order to access Backend service
Remember?
- We had to create 2 roles (based on templates provided by Backend service)
- We had to assign these roles to our user
One role ("Admin") was required for accessing the cockpit
The other role ("AllAccess") was required to call the APIs
Each role is tailored for exactly that scope:
A user who is Admin cannot call APIs
A user who has AllAccess, can access all APIs, but not the cockpit.
In order to properly learn Backend service, we assigned both roles to our user
As such, our user has the biggest possible scope.
But that’s not the desired setting for productive usage of software.
It is the opposite: the endeavor should be to narrow down the scope as much as possible.
Normal business users should not be allowed to do everything which is possible.
OK, what I wanted to say: Backend service defines a third scope.
This one allows to fine-tune the role configuration for users of APIs.
Below description shows how to do it.
In order to understand and follow this post, you need the following minimum requirements
API
You need an API in Backend service, so either choose an existing API or create a new API (see here)
You should verify that your user is allowed to call the API and gets the data as expected
Note:
In our examples we use a service called PRODUCTSERVICE which has an entity called Products
Role Configuration
You need to configure roles in SAP Cloud Platform, Cloud Foundry Environment, so you might wish to remember what you learned when going through this preparation blog.
Go to your Backend service cockpit, choose your API and take a note of the following information.
Furthermore, copy the URL of the API.
In our example:
https://subacc-backend-service.cfapps.eu10.hana.ondemand.com/odatav2/DEFAULT/PRODUCTSERVICE;v=1/
The configuration is done in 3 Steps:
1. Create Role
2. Assign Role
3. Trust Configuration
Note that these configuration steps are done for users who are existing
1. Create Role
In your subaccount, go to "Subscriptions" and click on "Backend service" to view the details (not open tool)
Expand "Security" and click on "Role Templates".
2 role templates are already known, now get familiar with the third one, "APIAccess" and the attributes
Understand: this role allows a user to access ONE entity of ONE existing API, in ONE version
A user who has this role assigned, is able to call this entity of this API, but nothing else
That’s the difference to the general role AllAccess. With the AllAccess role, a user can access all APIs and all entities of each API
To create a new Role, press on the button "New Role"
Enter a Name and Description of your choice
Choose "Template" as "APIAccess"
A new section is expanded which allows to enter the attributes required by this role template
To uniquely identify the protected resource which should be allowed for the owner of this role, it is necessary to enter all identifying parameters like name and version etc
Note:
You have to type the values manually, so be sure to enter the correct names.
After creating this role for this entity, you can go ahead and create more roles for different entities
2. Assign Role to Role Collection
Next is to assign the new role to a role collection
Go to your subaccount and expand the "Security" entry on the navigation pane on the left side of your cloud cockpit
Press “New Role Collection” and enter a name of your choice
After pressing “Save”, click on the new Role Collection hyperlink in the table in order to configure it.
In the “Roles” screen, press “Add Role” and enter the following details:
Application Identifier: this is the ID of Backend service application, which we have subscribed to.
If you have multiple entries in the drop down, choose the one with id "Backend-service!6131"
Next, choose the Role Template as APIAccess
Then you can select your role created above:
After pressing save, you have a new Role Collection which contains a new Role.
At this point in time you can decide to add more roles to this collection, or to create new collections with other roles.
Reason: the role collections are assigned to users, so to separate the access restriction between users, it is required to clearly separate the roles in different role collections
3. Trust Configuration
Next step is to assign the role collection to a user. This step depends on the setup of your landscape and how users are maintained.
The following description is based on Trial account.
Click on the menu entry “Trust Configuration” (in the “Security” entry of subaccount menu)
This time, don’t press “New Trust Configuration”, instead, click on the active identity provider
Enter the mail address of your user, then press “Show Assignments”
You might get this popup which you can confirm
I assume that your user already has a role collection assigned, otherwise you wouldn’t have been able to create/view the API
If yes, delete that assignment of role collection.
Then press the button “Assign Role Collection” and in the popup choose previously created role collection for one entity
Example:
Press “Assign Role Collection”
That's it.
Now your user is only allowed to call the entity “Products” of the service PRODUCTSERVICE in version 1
Test 1
First we check the good experience:
Open the Products:
https://<subacc>-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=1/Products
You receive a positive response, which is you don’t receive a negative response
Test 2
Now the bad experience:
Open a different entity, e.g.
https://subacc-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=1/Categories
You receive the expected negative response, the error message is understandable for us:
Test 3
Create the same PRODUCTSERVICE again, but this time with version 2
Note:
For this step we need to open the cockpit, but now we don’t have the permission anymore in our role collection.
To make life easier, it makes sense to add the Admin role to our user, this doesn’t invalidate our test. Make sure that you assign a role collection that does not contain the AllAccess role
So it makes sense to create a dedicated Role Collection which contains only the Admin role, then assign both Role Collections to our user in the “Trust Configuration” screen
Note:
If you’re working with only one user (your user) in Trial account, you need to change the role assignment for each test.
So don’t forget to deep refresh your browser each time, to make the changes effective.
Close all browser windows, clear all cached data, reopen browser etc
Now open the Products entity which was allowed in our first test, but this time choose service version 2:
https://subacc-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=2/Products
Now we get an error message, as expected:
“You do not have sufficient authorization to access API with name PRODUCTSERVICE, namespace DEFAULT and version 2”
Test 4
Create a role which for the attribute "EntityName" defines an asterisk instead of typing one entity
This means that all entities of this API are allowed
Assign this role to a new Role Collection, then assign this Role Collection (and the one with Admin) to your user, nothing else
Result:
Your user is allowed to call every entity set of the service
https://<subacc>-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=1/Products
and
https://<subacc>-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=1/Categories
BUT the user is not allowed to access any other service
Test 5
Continuing the above idea: why not enter 2 entities instead of one or instead of an asterisk?
You can try it.
However, you can believe me, currently it is not supported.
In this blog we've learned and proven that the privileges of a user can be configured in a way which allows for detailed differentiation.
Like that, a user can have access to a service, but open only one entity of it.
Useful, because data which is not required for his job can be hidden from him.
At the end, for fine granular restriction of access to APIs, we have 3 possibilities:
1. AllAccess:
User can call all APIs
2. APIAccess with *
User can call only this API, but all entities
3. APIAccess with explicit entity
User can call only this API, and only this entity
In Backend service subscription:
- create Role based on “APIAccess” and enter attributes for one entity
In Subaccount "Security":
- create Role Collection
- assign Role
In Subaccount "Security -> Trust Configuration":
- assign Role Collection to user
In the beginning of our series, we learned the initial configuration, required to get us up to speed.
That was:
Configure our Trial account to get access to the SAP Cloud Platform Backend service
Configure the roles which a user (our user) needs in order to access Backend service
Remember?
- We had to create 2 roles (based on templates provided by Backend service)
- We had to assign these roles to our user
One role ("Admin") was required for accessing the cockpit
The other role ("AllAccess") was required to call the APIs
Each role is tailored for exactly that scope:
A user who is Admin cannot call APIs
A user who has AllAccess, can access all APIs, but not the cockpit.
In order to properly learn Backend service, we assigned both roles to our user
As such, our user has the biggest possible scope.
But that’s not the desired setting for productive usage of software.
It is the opposite: the endeavor should be to narrow down the scope as much as possible.
Normal business users should not be allowed to do everything which is possible.
OK, what I wanted to say: Backend service defines a third scope.
This one allows to fine-tune the role configuration for users of APIs.
Below description shows how to do it.
Prerequisites
In order to understand and follow this post, you need the following minimum requirements
API
You need an API in Backend service, so either choose an existing API or create a new API (see here)
You should verify that your user is allowed to call the API and gets the data as expected
Note:
In our examples we use a service called PRODUCTSERVICE which has an entity called Products
Role Configuration
You need to configure roles in SAP Cloud Platform, Cloud Foundry Environment, so you might wish to remember what you learned when going through this preparation blog.
Preparation
Go to your Backend service cockpit, choose your API and take a note of the following information.
| Attribute | Example |
|---|---|
| APIName | PRODUCTSERVICE |
| APINamespace | DEFAULT |
| APIVersion | 1 |
| EntityName | Products |
Furthermore, copy the URL of the API.
In our example:
https://subacc-backend-service.cfapps.eu10.hana.ondemand.com/odatav2/DEFAULT/PRODUCTSERVICE;v=1/
Fine granular configuration
The configuration is done in 3 Steps:
1. Create Role
2. Assign Role
3. Trust Configuration
Note that these configuration steps are done for users who are existing
1. Create Role
In your subaccount, go to "Subscriptions" and click on "Backend service" to view the details (not open tool)
Expand "Security" and click on "Role Templates".
2 role templates are already known, now get familiar with the third one, "APIAccess" and the attributes
Understand: this role allows a user to access ONE entity of ONE existing API, in ONE version
A user who has this role assigned, is able to call this entity of this API, but nothing else
That’s the difference to the general role AllAccess. With the AllAccess role, a user can access all APIs and all entities of each API
To create a new Role, press on the button "New Role"
Enter a Name and Description of your choice
Choose "Template" as "APIAccess"
A new section is expanded which allows to enter the attributes required by this role template
To uniquely identify the protected resource which should be allowed for the owner of this role, it is necessary to enter all identifying parameters like name and version etc
Note:
You have to type the values manually, so be sure to enter the correct names.
After creating this role for this entity, you can go ahead and create more roles for different entities
2. Assign Role to Role Collection
Next is to assign the new role to a role collection
Go to your subaccount and expand the "Security" entry on the navigation pane on the left side of your cloud cockpit
Press “New Role Collection” and enter a name of your choice
After pressing “Save”, click on the new Role Collection hyperlink in the table in order to configure it.
In the “Roles” screen, press “Add Role” and enter the following details:
Application Identifier: this is the ID of Backend service application, which we have subscribed to.
If you have multiple entries in the drop down, choose the one with id "Backend-service!6131"
Next, choose the Role Template as APIAccess
Then you can select your role created above:
After pressing save, you have a new Role Collection which contains a new Role.
At this point in time you can decide to add more roles to this collection, or to create new collections with other roles.
Reason: the role collections are assigned to users, so to separate the access restriction between users, it is required to clearly separate the roles in different role collections
3. Trust Configuration
Next step is to assign the role collection to a user. This step depends on the setup of your landscape and how users are maintained.
The following description is based on Trial account.
Click on the menu entry “Trust Configuration” (in the “Security” entry of subaccount menu)
This time, don’t press “New Trust Configuration”, instead, click on the active identity provider
Enter the mail address of your user, then press “Show Assignments”
You might get this popup which you can confirm
I assume that your user already has a role collection assigned, otherwise you wouldn’t have been able to create/view the API
If yes, delete that assignment of role collection.
Then press the button “Assign Role Collection” and in the popup choose previously created role collection for one entity
Example:
Press “Assign Role Collection”
That's it.
Now your user is only allowed to call the entity “Products” of the service PRODUCTSERVICE in version 1
Test the role-based access
Test 1
First we check the good experience:
Open the Products:
https://<subacc>-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=1/Products
You receive a positive response, which is you don’t receive a negative response
Test 2
Now the bad experience:
Open a different entity, e.g.
https://subacc-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=1/Categories
You receive the expected negative response, the error message is understandable for us:
Test 3
Create the same PRODUCTSERVICE again, but this time with version 2
Note:
For this step we need to open the cockpit, but now we don’t have the permission anymore in our role collection.
To make life easier, it makes sense to add the Admin role to our user, this doesn’t invalidate our test. Make sure that you assign a role collection that does not contain the AllAccess role
So it makes sense to create a dedicated Role Collection which contains only the Admin role, then assign both Role Collections to our user in the “Trust Configuration” screen
Note:
If you’re working with only one user (your user) in Trial account, you need to change the role assignment for each test.
So don’t forget to deep refresh your browser each time, to make the changes effective.
Close all browser windows, clear all cached data, reopen browser etc
Now open the Products entity which was allowed in our first test, but this time choose service version 2:
https://subacc-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=2/Products
Now we get an error message, as expected:
“You do not have sufficient authorization to access API with name PRODUCTSERVICE, namespace DEFAULT and version 2”
Test 4
Create a role which for the attribute "EntityName" defines an asterisk instead of typing one entity
This means that all entities of this API are allowed
Assign this role to a new Role Collection, then assign this Role Collection (and the one with Admin) to your user, nothing else
Result:
Your user is allowed to call every entity set of the service
https://<subacc>-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=1/Products
and
https://<subacc>-backend-service.<...>/odatav2/DEFAULT/PRODUCTSERVICE;v=1/Categories
BUT the user is not allowed to access any other service
Test 5
Continuing the above idea: why not enter 2 entities instead of one or instead of an asterisk?
You can try it.
However, you can believe me, currently it is not supported.
Summary
In this blog we've learned and proven that the privileges of a user can be configured in a way which allows for detailed differentiation.
Like that, a user can have access to a service, but open only one entity of it.
Useful, because data which is not required for his job can be hidden from him.
At the end, for fine granular restriction of access to APIs, we have 3 possibilities:
1. AllAccess:
User can call all APIs
2. APIAccess with *
User can call only this API, but all entities
3. APIAccess with explicit entity
User can call only this API, and only this entity
Appendix: Quick Reference
In Backend service subscription:
- create Role based on “APIAccess” and enter attributes for one entity
In Subaccount "Security":
- create Role Collection
- assign Role
In Subaccount "Security -> Trust Configuration":
- assign Role Collection to user
- SAP Managed Tags:
2 Comments
