| Cash Management Demo App | |
|---|---|
| URL | https://app.clearentitlement.com/demo |
| Usernames | paymentmaker1, paymentmaker2, paymentchecker1, paymentchecker2, paymentchecker3 |
| Password | ClearEntitlement@1 |
| Notes |
Try login and create/approve payments. Transactions are auto
deleted in 5 minutes. paymentmaker1 max amount is 500, and paymentmaker2 max amount is 1000. |
| Admin Console | |
|---|---|
| URL | https://app.clearentitlement.com |
| Username | readonly |
| Password | ClearEntitlement@1 |
| Notes |
View payment app policies and user entitlements. Clear Entitlement IdP SSO is enabled, please logout before switch between demo app and admin console. |
Use Case and Policy Model
- XYZ Bank offers a Cash Management Service with Payment Approval Workflows for corporate customers.
- The cloud services integrate Clear Entitlement for functional entitlement, data entitlement, and data redaction.
- An application role schema has been established to facilitate the definition of policies using account numbers and maximum allowable payment amounts.
- Two application roles, paymentMaker and paymentChecker, have been created based on the aforementioned schema to facilitate the payment workflow.
- A Segregation of Duties (SoD) rule is implemented to prevent a user from holding both the paymentMaker and paymentChecker roles simultaneously.
- Create policies for initiating and approving payments, assigning the paymentMaker and paymentChecker roles as corresponding subjects. Include conditions to limit access to authorized accounts and ensure that the amount does not exceed the maximum allowed.
Provisioning
|
Customers have the flexibility to provision user entitlements
using the SCIM API or manage entitlements through the
out-of-the-box SCIM UI. When using the Clear Entitlement UI, the UI schema determines the appearance and structure of the UI. In this demo app, we use account and amount pairs to control access. The application role's schema: {..., accountAndLimit":{"ui:title":"Account and Max Amount","items":{"ui:title":" ", "account":{"ui:title":"Account"}, "maxAmount":{"ui:title":"Max Amount"}}}...} results in a UI like the one shown in this screenshot. For details, log in to the admin console and view the application role schemas for the Payment Demo App. |
|
Entitlement Service Integration
- To dynamically adjust the UI elements such as menu items, buttons, tabs, and links based on user permissions, the system utilizes the 'Query Functional Entitlements' API to retrieve functional entitlements for either the entire resource tree or a specific branch. For instance, users with the 'paymentMaker' role will see the 'make payment' menu item, while those with the 'paymentChecker' role will see the 'view payment requests' menu.
- During the payment process, users select a payee, choose an account, and enter an amount. To display only authorized accounts, the system retrieves a filter using the 'Get Filter' API and applies it to the account list.
- When a payment request is submitted, the backend utilizes the 'Check Access' API to verify whether the current user is authorized to make the payment, regardless of any frontend checks.
- Similarly, when a user with the 'paymentChecker' role views payment requests, the system employs the 'Get Filter' API to obtain a filter and applies it to the payment request list, displaying only authorized transactions for approval.
- Subsequently, when a payment approval or rejection is submitted, the backend once again leverages the 'Check Access' API to validate the user's authorization status, disregarding any frontend validations.
It's important to note that while UI integrations such as displaying authorized menu items, buttons, and accounts enhance user experience, they can be bypassed with generated requests on the fly. Therefore, server-side permission checks performed by the APIs are essential for ensuring security and adherence to access control policies.
Functional Entitlement
Functional entitlements mainly concern configuring the UI. For example, in the demo app, the payment maker and checker see different menu items.
What a payment maker sees: |
What a payment checker sees: |
Single Value Filter
Show authorized items based on a single entitlement attribute, such as which account a payment can use.
Candidate accounts for payment maker1: |
Candidate accounts for payment maker2: |
Composite Filter
Perform data redaction based on multiple entitlement attributes. This often involves pagination and is the most challenging part of authorization services.
Show only the payment requests that payment checker1 can approve:  |
Show only the payment requests that payment checker2 can approve: |
API Protection
For each protected API, either perform data redaction to return only authorized items or verify access to ensure the request is authorized.
- When submitting a payment request, ensure the current user has permission to make the payment. Additionally, verify that the payment account and amount are within the authorized scope.
- When approving a payment request, ensure the current user has permission to approve the payment. Additionally, verify that the payment account and amount are within the authorized scope.
Copyright 2023 All Right Reserved