This page describes some of the concepts behind the Indent Platform.
A collection of Resources, providers and configurations for a team or organization.
An interface for Indent to interact with remote systems. Every Resource is registered by an integration; without integrations, Indent wouldn't know about the outside world. Indent uses an integration and Integration Configuration when:
- Applying changes from petitions
- Pulling updates from third-party systems
- Messaging users for review
Related: How integrations work · Working with webhooks Terraform Providers
A set of options and credentials used to configure an Integration when Indent needs to interact with an external system or to extend Indent with custom resources and behavior.
Related: Terraform Provider Configuration
An API object of a certain kind as registered or managed by a Provider. For example, the groups found in a specific Okta domain - each of which are resources. These can also be entirely custom objects like accounts in a production database.
Related: Terraform Resources · Kubernetes Custom Resources
An interface to manage changes to any custom resources whether they're in external systems (e.g. identity providers, cloud apps) and internal systems (e.g. databases, home-grown tools).
Related: How petitions work · Sample petition
An event can refer to either an action by a user, service account or automated system function. Events have a name (for example
sso.login) and a specification for how to represent audit log events to capture: "Who did what, when, where and why?" to preserve semantics of audit logs between a variety of Providers, regardless of where it originated.
An Event that is validated for its authenticity by a Provider and the authorization of the actor. For example, when a reviewer approves a Petition in Slack, a claim is created for that actor by the integration for that Provider.
Any action required to satisfy a Task by the Indent system is called a Command.
- Requesting access, approving, granting or revoking a request are all Commands for example.
- Petitions step through a series of Commands to plan, review and apply the changes.
- Every Command is recorded in the Audit Logs as an Event. For example, the grant access Command is recorded as a corresponding
A set of conditions and rules evaluated for Petitions and Reviews that determine requirements that must be met to satisfy the policy. For example, someone on the engineering team needs to approve so Indent will message the
#engineering channel for visibility, but require approval from a senior team-member.
A process step that enables teams to efficiently keep group memberships, access to apps, and roles under control. User access can be reviewed on a regular basis to make sure only the right people still have access.
A configuration that defines a required set of Claims to be validated, like a requester's manager has to approve and has to have a certain field on their profile from an identity provider. They are the outcome of a Policy evaluation for a given Petition.
A task represents the work and context needed to satisfy a Requirement. The most common task is a Review, since it's an essential continuous step for securing everyday access.