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.

Screen capture of an example bank permission policy checking whether the BankUserId attribute value matches the BankAccount.owner attribute value, and whether the BankAction attribute value matches the "transfer" constant

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.

Screen capture of an example AccountCollection attribute resolving from a constant
Screen capture of an example BankAccount attribute with query settings enabled and the AccountCollection attribute specified as the source.

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.