Authorization onboarding, administration, and enforcement

The authorization onboarding involves onboarding service policies and service types for fine grained access control.

Authorization onboarding

Onboarding service policies

In order to use the Identity and Access Management (IAM) services for enforcing authorization, a content service would define its service policies; which is a JSON file mapping of what endpoints can be accessed with what role for the service. For more information, see the service policy onboarding example.

Note: When the service policies are onboarded to IBM Cloud Private, as with the action-role mapping and when the APIs are accessed via the IBM Cloud Private's management ingress port 8443, they are access restricted automatically by the IAM's Access Control Gateway. The Access Control Gateway checks for the user's access against their role for any access to these APIs.

Onboarding service type and instances

It is mandatory to onboard the service type so that the content service can make IAM aware of its service type and service instances so that they are available for authorization enforcement via the UI or API.

In IBM Cloud Private, the service types and service instances are auto-discovered for role-based action control (RBAC) administration in the team. For the auto-discovery to happen, when the workload's chart is deployed and the service policy is defined, as explained in the previous step, it is important that the "chartName" is specified. For example: "chartName": "sample-api".

Authorization administration

Fine grained access control can be achieved for a content workload at the following levels:

During team administration, the charts that are identified with the chartName attribute at install time are listed on the Resources page for service types. The releases or the service instances are also auto-discovered. This allows users to choose the chart/service type and/or the release/service instance to apply role based access controls. Fine grained access control at the level of resource type and resource instance is possible but they are free text entries.

Authorization enforcement

When the team RBAC is defined in IBM Cloud Private by using the previous pattern, authorization can be enforced at the API level. See PDP bulk AuthZ API for an example of API request responses that shows how the policy/access enforcement can be done through the APIs.

Setup non-user driven use cases

It is possible to drive non-user driven use cases for the purpose of the content workloads using the service-id and api-key concept in IBM Cloud Private. The details of administering service-id, api-key and the associated policies are discussed in greater detail in the respective section of its own. The following are sample use cases that workloads have that need to be driven by a non-user entity: