Skip to Content
Technical Articles

SAP Cloud Platform Backend service: Tutorial [16]: Fine-Tuning Role Configuration

This blog is part of a series of tutorials explaining the usage of SAP Cloud Platform Backend service in detail.

Quicklinks:
Config
Reference

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

 

1 Comment
You must be Logged on to comment or reply to a post.
  • Thanks for explaining about the security concepts.

    I think it would also be already very helpful if you could specify the type of access (read/write/create/delete), or maybe the Method (GET/POST/PUT/DELETE)? And definitely a list would be great as well like you already mentioned: e.g. “PRODUCTS;CATEGORIES”.

    Eventually what would be great it attribute type access as well. E.g. only show me orders of my region (where country = ‘DE’) or only my orders (where seller = {me}). If it would be possible to set that type of access, it would almost become unnecessary to have a back-end application on top of BaaS. Instead BaaS could potentially be access from the front-end (UI5) directly!