Authorization actions
Use an Authorization action to decide whether a signed-in person may access a service, and to derive the group or permissions that the journey can use. It works with trusted identity information already available to the service.
Authorization is a security boundary. Configure it with the identity and security owners, apply least privilege, and test both permitted and denied users before deployment.
Design the access rule
Express the rule in simple business language before writing a Liquid template: for example, “Only members of the approved organisation group may access this service” or “Only people with the reviewer permission may continue.”
flowchart LR
A[Signed-in identity information] --> B[Authorization action]
B --> C{Access rule passes?}
C -- Yes --> D[Store permitted group and permissions]
C -- No --> E[Show access-denied content]Do not use this action to make a cosmetic page decision. It decides whether a person can access the service. Use ordinary conditions for in-service branching after access has been granted.
Configure the action
- Add an Authorization action at the earliest appropriate point in the service access route.
- Set a stable Action ID and a name that describes the policy, such as
allow_approved_organisation_users. - Set the Authorization check template to return a clear true or false result from trusted identity data.
- Write Access denied content that explains what happened and how the person can get help.
- Configure a user-information template only where the service needs it from the approved identity source.
- Extract a group ID or permissions only when the service has a documented use for them.
- Test with accounts that should be allowed, denied and have incomplete identity information.
Keep the access check small and readable. If the rule becomes a long, hard-to-review expression, define the policy and identity attributes more clearly before implementing it.
Use trusted identity information only
The user-information, group and permissions templates derive values from the authenticated identity context. Use only attributes supplied or approved by the identity provider. Do not grant access based on unvalidated form input, URL parameters or values that a person can change in the service.
When you store a group ID or permissions for later templates and conditions, use consistent, documented values. A role-based condition can be useful after access is granted, but it must not become an alternative path around the initial authorization check.
Write a helpful access-denied message
Access denied content supports Markdown. Explain plainly that the person cannot access the service, give a safe route to request access or contact support, and avoid revealing internal role names, user records or the existence of other accounts.
Do not make people guess whether a technical issue or a policy decision blocked them. Keep the message concise, include an alternative contact path, and test it with a keyboard and screen reader as well as visually.
Maintain the access policy
Document the policy owner, identity attributes used, permitted groups or permissions, review interval and emergency revocation path. Re-test whenever identity claims, directory groups or organisation structure changes.
Test the service after signing in as each key role. Include a user with no matching group, a user with multiple groups, a user whose optional attribute is absent and a user whose permission has been removed. Check that denied users cannot reach restricted content through browser history or a direct link.
Test checklist
- The access rule reflects an approved business policy.
- It uses only trusted authenticated identity information.
- Permitted, denied and incomplete-identity cases have been tested.
- The denied message is clear, safe and accessible.
- Stored group and permission values have a documented purpose.
- Conditions using permissions cannot bypass initial access control.
- The policy has a named owner and review process.