Authorization onboarding, administration, and enforcement
The authorization onboarding involves onboarding service policies and service names 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 your product, as with the action and role mapping, and when the APIs are accessed via the management ingress port 443 of your product, their access is automatically restricted by the Access Control Gateway of the IAM. The Access Control Gateway checks for the user access against their role for any access to these APIs.
Onboarding service name and instances
It is mandatory to onboard the service so that the content service can make IAM aware of its service name and service instances so that they are available for authorization enforcement via the UI or API.
When you define the service policy, it is important that the "name" is specified. For example: "name": "sample-api".
Authorization administration
Fine grained access control can be achieved for a content workload at the following levels:
- Service name
- Service instance
- Resource type
- Resource instance
During team administration, the services that are identified with the name attribute at install time are listed on the Resources page for service names. Fine grained access control at the level of resource type and resource instance
is possible but they are free text entries.
Authorization check
When the team RBAC is defined in your product by using the previous pattern, authorization can be checked at the API level. See PDP AuthZ APIs for examples of API requests and responses that show how the policy or access check 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 by using the service-id and api-key concept in your product. 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:
- Service IDs can be used to authorize applications using content workloads.
- Service policies bound to service IDs are used to authorize access to resources.