Use case: controlling financial resources
Policy queries enable you to dynamically generate user interfaces with open-ended decision requests and access control logic defining user permissions.
To see how you might use policy queries to dynamically drive a user interface as part of your financial authorization flow, consider the kinds of questions pertinent to controlling bank customers' access:
-
Which accounts can this customer request a transfer from?
-
Which accounts can this customer withdraw from?
-
Which actions can this customer perform on a specific checking account?
Suppose you are a bank and want to control which accounts are displayed to a customer attempting to make a transaction.
Instead of executing a batch of decision requests to determine which accounts or actions a subject is permitted to access, policy queries enable you to execute a single decision request that returns a collections of values, rather than a simple Permit
or Deny
.
First, you create attributes and sub-attributes in your Trust Framework to represent the subjects, actions, and resources around which you want to build access control policies:
-
BankAccount
: Represents the financial resources you want to protect.-
BankAccount.owner
: Represents the owner of a given protected resource.
-
-
BankAction
: Represents the range of actions customers want to perform on your protected resources. -
BankUserId
: Identifies the customer requesting to act on an account.
Using these attributes as a foundation, you then create policies to model the desired business logic. In the following example, the policy checks both whether the requesting customer owns the account that they want to act on, and whether the requested action is transfer
. If either of these conditions is not met, the decision engine returns Deny
. Otherwise, it returns Permit
.
Next, you enable query settings for each attribute that you want to leave valueless in a query decision request. If you want to know which accounts a given customer can charge, you must enable query settings for the BankAccount attribute. Remember that after you enable query settings, you must specify a source collection attribute for the query attribute to resolve from. In this example, the BankAccount attribute is configured as a query attribute with an AccountCollection source attribute that resolves from a collection constant.
At a more technical level, when a query attribute is not assigned a value in a query decision request, the decision engine executes a batch of decision requests made to the JSON PDP API to determine which accounts return a Permit
decision and which accounts return a Deny
decision, given relevant context. Using the returned collection of accounts that the customer is authorized to act on, your application learns which accounts to display based on the requesting customer’s ID, the relevant account’s owner, and the requested action.