SaaSLayer Permissions Documentation
SaaSLayer Permissions is an authorization platform for SaaS products that need tenant-aware roles, fine-grained policies, auditability, and fast permission checks without outsourcing every decision to a metered external service.
The platform is built around a simple idea: model your authorization graph once, materialize effective permissions for each principal, and make application checks cheap enough to run everywhere you need them.
What you can build
Use SaaSLayer Permissions when your product needs:
- Tenant and workspace isolation
- Organization, tenant, and group membership
- Roles with permissions and inheritance
- Policies with conditions such as ownership, amount, environment, IP range, or time
- Permission boundaries for maximum-access limits
- Per-resource grants for sharing individual objects
- Delegated sessions for support, agents, and service accounts
- Approval workflows for access changes
- Audit trails for who changed or used access
How the docs are organized
| Guide | Use it when |
|---|---|
| Quickstart | You want to create the first users, roles, policies, and permission check. |
| Core Concepts | You need the mental model: principals, resources, scopes, roles, policies, and grants. |
| Model Your Authorization | You are designing a production tenant model and deciding where roles and policies belong. |
| Permission Checks | You are integrating authorization checks into an application or API. |
| Policies and Conditions | You need attribute-based rules, ownership checks, or Cedar-authored policies. |
| Delegated Sessions | You need support access, service-account assumption, or temporary agent permissions. |
| Federated Principal Auth | You want to replace long-lived SaaSLayer API keys with OIDC, AWS IAM, or Kubernetes workload identity. |
| Agent Delegation | You need AI agents or automation to act on behalf of users with bounded, auditable authority. |
| Access Requests | You want users to request access and route approvals to the right reviewers. |
| Event Delivery | You need webhook or EventBridge notifications for approval prompts and lifecycle events. |
| Operations and Audit | You need to understand cascades, history, audit logs, and safe change workflows. |
API reference
Every deployment serves its full OpenAPI 3.1 document (REST routes plus webhook event contracts) at GET <your Permissions API base URL>/openapi.json. The endpoint is public (no auth) and servers[0].url is set to the URL you called it on, so you can load it straight into Scalar, Swagger UI, Postman, or a client generator.
The normal implementation path
- Create your top-level organization and tenants.
- Add users, agents, or service accounts as principals.
- Define roles that match product responsibilities.
- Attach permissions or policies to roles.
- Assign roles to principals at the right scope.
- Check permissions from your app using
/permissions/check. - Add conditions, grants, boundaries, sessions, and approvals as your product matures.
Start with coarse roles and explicit permission checks. Add policy conditions and access workflows only where they solve a concrete product problem.