It should be noted that it is not the intention of SAP Cloud Platform to implement a Governance , Rick Management & Compliance (GRC) solution but rather enterprises should consider using their existing Single Sign-On solutions which will have all the reports and controls in place to manage and report user access and roles to the cloud platform, either directly or through the Identity and Authentication Services (IAS)
In essence there are three pieces to authorization on the NEO platform. This is the user, the role and the group.
Central to this is the User. A user can have roles assigned to them manually or they can be assigned to zero or more groups then within those groups they will then inherit the roles defined in the group. Each group thus is composed of users and roles.
A Role is defined by the scopes that it contains. SAP provide a number of default roles which can be further customized in the “Platform Roles” panel
If you look at assigning roles you will see there is another account name and an application name. Getting your head around what are termed provider and consumer account can be challenging and can be quite confusing initially.
SAP provides a number of services as part of the platform such as WebIDE, Workflow or Integration. These services are managed with what is termed a provider subaccount. When they are deployed to your subaccount, when activated by a contract or entitlements, your subaccount becomes the consumer account. As part of this, the applications that go with the provider account are deployed to your tenant and so access to these applications needs to be controlled. This is done through the use of the roles. Adding a role to a user or a group requires the provider account and the application name. This will give a set of roles that can then be assigned to the user or group.
For services that require a provider account they will expose a number of applications in your cockpit (some visible, some not). These applications will then have a set of roles that define operations for the specific application that a user having those roles are allowed to do. What this means is that when adding a role to a user this requires the provider subaccount and the application. These two define the roles that are available to be assigned to the user and they will be checked by the applications when the user attempts to execute an operation that is protected by one of those roles.
The API for authorization management consist of API endpoints to extract all 3 of these. From the User API you can get the group and roles. From the Group API you can get the users and roles and from the Roles API you can get the assigned users and groups for the specific provider subaccount and application.
Since I have already explained how to create an oauth token in the two previous posts, I will skip the processes as I a sure you are all already bored of it.
As per the above document with all the API’s, to access the groups we go to
https://api.<data centre>.hana.ondemand.com/authorization/v1/accounts/<technical account name>/groups
This will return a list of the group names in the current sub account.
What is slightly unclear in the documentation is how to access the users and the roles in the group collection itself
This is passed as a parameter called groupName in the URL as so:
https://api.<data centre>.hana.ondemand.com/authorization/v1/accounts/<technical account name>/groups/users?groupName=<group name>
So if we use the previous example above, we can get all the users in the group by using the group name “Integration Dev”
Likewise we can repeat the exercise to get all the roles assigned to the group
https://api.<data centre>.hana.ondemand.com/authorization/v1/accounts/<technical account name>/groups/roles?groupName=<group name>
Here we get the “Integration Dev” group’s roles that are defined on the sub account.
With a user it is possible to get their roles and their groups through the API. Here the query parameter name is userId and not groupName.
Similar to what we had above, we can use the URL:
https://api.<data centre>.hana.ondemand.com/authorization/v1/accounts/<technical account name>/users/roles?userId=<user id>
Here you can see the list of roles that are assigned to the user.
Likewise you can repeat the exercise with the groups the user belongs to.
https://api.<data centre>.hana.ondemand.com/authorization/v1/accounts/<technical account name>/users/groups?userId=<user id>
And as would be expected this matches what you see in the cockpit.
The last point on the triangle is the Roles. This is the most complex and for the most part you will not need it. A role is defined by both the application that has defined it and the provider account if the role is managed by an SAP service. As you can see when you assign a role to a user in the cockpit you need to select both the provider account (service) and the application (in your subaccount) then select the role from that.
Right now I have not found an API to extract the list of applications or provider accounts so to find the roles you will need to supply the provider subaccount and the application name in order to extract the roles and groups assigned to that application and provider. You will thus need to look them up in the cockpit. Fortunately these do not change.
As you can see the URL
https://api.eu1.hana.ondemand.com/authorization/v1/accounts/<technical account name>/apps/<appname>/roles?providerAccount=<provider account>
will provide the list of roles that the provider and application define for consumption in the consumer account
Likewise to get a list of the users assigned that role on your tenant you can use the following URL
https://api.eu1.hana.ondemand.com/authorization/v1/accounts/<technical account name>/apps/<appname>/roles/users?providerAccount=avrhcid&roleName=IntegrationOperationServer.developer
will provide a list of the users who have that role in your subaccount
Finally we can repeat the exercise to get a list of the groups that have that role assigned to them
As you can see from above there is a group called workshopp that has the role defined in it.