Skip to main content
← All capabilities
Available now

Platform capability · Authorization

Decide access by role, by attribute and by relationship in one check

Roles, attribute rules and resource hierarchies in one permission system

A permission system that combines inherited roles, attribute rules, resource hierarchies, grants on single records and a separate set of roles for operators. Each app lists what it protects, and the actions on it, in its app declaration. Publishing the app registers them with the permission system.

Built in

What you get

  • Each app declares its resource types and actions
  • Roles can inherit from other roles, and are kept in each organization’s own database
  • User groups: give a set of roles to a whole team at once, and take them away by removing a member
  • Customers can define their own roles next to the ones your apps supply
  • Permissions on single records
  • Permissions pass from a parent resource to its children
  • Attribute rules that combine sets of users with sets of resources
  • Permissions for visitors who are not signed in, for public pages
  • A separate set of roles for platform operators
  • Starter sets of roles for each app
  • A log of every decision. A past decision can be checked again against today’s rules to find what changed
  • Rules written as policies that you can test and version before they take effect
  • Delegated access that expires and can be revoked, with actions recorded as done on someone’s behalf
  • Roles assigned automatically from user attributes
  • Checks run inside each service and are cached to keep them fast
  • One client library for every backend and frontend
Under the hood

How it works

Roles, attribute rules and relationships in one decision

SaaS products often need roles, attribute rules and resource relationships together. SynaptaGrid checks all three in one decision: NIST-style role-based access control, deny-overrides conditions in the style of OASIS XACML, and relationship grants in the style of Zanzibar.

Your app supplies starter roles, and customers add their own

The app declaration lists the app’s starter roles, and publishing makes them available to every customer. Roles that a customer defines stay separate from the roles the app supplies. Groups assign roles to teams, and group membership can follow Entra ID, Okta or Active Directory through the provisioning connector you configure.

Publishing an app registers what it protects

An app lists its resource types and actions in its app declaration. On deployment the platform publishes the app’s resources, actions and starter roles to a versioned catalog that every customer reads. Customers can adopt the starter roles or replace them, and nothing is copied into each account. Adding a new app needs no manual setup in admin screens.

Customer roles and operator roles are separate

Roles inside a customer workspace and roles for your operators are checked separately. Operator permissions cover support access, billing work and incident response, and are not treated as customer roles.

Built to be checked on every request

A permission check runs on every request, so the system is built to cache which permissions each role gives, which resources belong to each set and the results of rules. Tuning this cache for production load is part of setting up each deployment. It is not done by default.

Decisions can be reviewed, tested and time-limited

Each decision records what went into it and the result, for later review. Operators can run a past decision against the current rules, test a rule change before applying it, and give delegated access that expires. Actions taken under delegation are recorded in the audit trail as done on someone’s behalf.

Want a deeper walkthrough of Authorization?

A solution architect will demo the live service against your domain model.

Get a deployment assessment