Defining operations for protected actions
Operations in PingOne Authorize enable you to use built-in access control rules or custom policies to control access to API actions.
About this task
An API service operation is a method and path combination that matches a client request to the API. Add operations for API requests that you want to protect.
You can define up to 25 operations for each API service in an environment. |
When PingOne is managing user directory services and access token validation for an API service, you can define built-in access control rules and custom policies for an operation. When these services are managed externally, you can define custom policies for an operation, but you can’t configure built-in access control rules.
Access control rules
Built-in access control rules grant access to protected operations based on:
-
User membership in groups. Before you grant access based on group membership, you must add users and create groups in PingOne.
-
Authorized OAuth scopes. Scopes determine the resources that a client can access. For example, a banking application might use scopes to control the kinds of data shared with third-party applications.
-
Authorized permissions. Before you grant access based on permissions, you must define permissions for the application resources that you want to protect.
PingOne Authorize automatically generates policies for built-in access control rules and deploys them when you deploy the associated API service.
For hands-on experience with defining access control rules for an API operation, see Tutorial 2: Controlling access to specific API operations. |
Custom policies
Custom policies handle more complex authorization scenarios, such as evaluating context by pulling in risk scores to determine access. You can enable custom policies when you define an API service or by editing the API service later.
The following steps provide information about configuring built-in access control rules for an operation. For more information about custom policies, see Adding custom policies for API services and operations.
Steps
-
Go to Authorization → API Services.
-
Select your API service, and then click the Operations tab.
-
To create a new operation, click Define Operation.
-
Click Methods, and then select one or more methods for the operation. Press Tab or click outside the list to close it.
-
Enter one or more API Paths for the operation.
Paths must start with a slash (/) and match requests for resources and subresources exactly unless you use wildcards or parameters.
-
A single wildcard (*) represents one path segment.
-
A double wildcard (**) represents one or more segments at the end of the path.
-
Surround parameters with curly braces ({}). You can add attributes that represent path parameters to make them easy to use in custom policies. For more information, see API Access Management attributes.
For examples of path definitions and matching requests for account resources and subresources, such as transactions, expand the following section. Only a few of the possible matches are shown for paths with wildcards.
Example path definitions and matching requests
Path Examples of matching requests /accounts/{accountId}/transactions/*
/accounts/123/transactions
/accounts/123/transactions/
/accounts/123/transactions/456
/accounts/123/transactions/details
/accounts/*/transactions/*
/accounts/123/transactions
/accounts/123/transactions/
/accounts/123/transactions/456
/accounts/123/transactions/details
/accounts/{accountId}/**
/accounts/123/transactions
/accounts/123/transactions/
/accounts/123/transactions/456
/accounts/123/transactions/details
/accounts/123/transactions/details/statement
/accounts/123/settings
/accounts/{accountId}/transactions/
/accounts/123/transactions/
Matching requests must end with a slash (/).
/accounts/{accountId}/transactions
/accounts/123/transactions
Matching requests must not end with a slash (/).
For more information, see Path Parameter Pattern Syntax.
To add another path, click Add Path.
-
-
For Name, enter a name that describes the operation.
You can change the default name, which consists of the method and path separated by request for.
-
If user directory services and access token validation are managed externally for the API service, click Save, then click Deploy.
Built-in access control rules are not available in this situation. Instead, use your external providers, such as PingFederate and PingDirectory, to configure authorized scopes and user groups.
-
To define access control rules, click Next.
-
Optional: Define a group-based rule:
-
Select the The user must be a member of any of these groups check box.
-
Click the Groups list, and then select one or more groups. Press Tab or click outside the list to close it.
-
-
Optional: Define a scope-based rule:
-
Select the Client must be authorized with these scopes check box.
-
Click the Scopes list, and then select one or more scopes. Press Tab or click outside the list to close it.
-
Optional: To add a new scope, in the Scopes list, enter the name of the scope, and then press Enter.
-
Click the toggle to change whether all or any of the scopes must be authorized:
-
All (default): Allows access if a client is authorized for all of the scopes. This is equivalent to adding a Boolean AND operator between scopes.
-
Any: Allows access if a client is authorized for any of the scopes. This is equivalent to adding a Boolean OR operator between scopes.
All and Any have the same effect when there’s only one scope.
-
-
-
Define a permission-based rule:
-
Select the The user must have this permission check box.
-
Click the Permission list, and then select a permission.
The list includes all of the permissions that are available for the PingOne resource associated with the API service.
-
-
Click Save.
-
Click Deploy.
Next steps
If you configured a scope-based rule for the operation, make sure that you grant the same scopes to your PingOne application to ensure that clients are allowed to access the API operation. To do this, edit the list of allowed scopes on the application’s Resources tab. For more information, see Editing scopes for an application.
If you configured a permission-based rule for the operation, make sure that you assign permissions to roles, and assign roles to users.