Concepts
Oblique provides an authorization system that lets you specify who should have access to what, and why they have that access.
Oblique uses a few core objects to represent the entities in your organization:
- Users: Individuals who can access resources, such as employees
- Groups: Collections of users that can be attribute-based with automatic membership based on user properties, reporting groups with automatic membership based on reporting hierarchy, or manually managed team groups
- Integrations: External systems connected to Oblique to sync objects and write access decisions
- Resources: Objects in external systems that require access control
- Accounts: Profiles in integrations that are granted access in those systems, which are often mapped to users
- Entitlements: Positive access grants that define a relationship between a subject and a resource, which can include expiry dates and justifications. A user or group has access to a resource when they have one or more entitlements that grant access to that resource
Users are individuals in an organization who can access resources. Not all users are employees—they may also be contractors or interns.
Attributes
Section titled “Attributes”Attributes represent properties of a user, which define their identity in an organization. For example, location, department, or employment type are user attributes.
Attributes can come from multiple integrations. Attributes are namespaced by their integration source.
When multiple integrations provide the same user information (like title or manager), core attributes determine which integration’s data appears in user profiles.
Groups
Section titled “Groups”Groups represent collections of users. Users who belong to a group become members of the group.
Groups can be attribute-based groups, reporting groups, or team groups, but not multiple types. A group cannot contain both automatically and manually managed members.
Attribute-based groups
Section titled “Attribute-based groups”Attribute-based groups use a set of attributes to define membership.
Attribute-based groups define employees who have similar functional roles or job requirements. For example, an attribute-based group “Support” would include all users in the Support cost center. A group “San Francisco employees” would include all users in San Francisco who work full-time.
Attribute-based groups:
- Automatically update when attributes change. Oblique automatically adds all users with the specified set of attributes to the group. You can’t manage attribute-based group membership manually.
- Require a user to match all attributes exactly. You can’t create an attribute-based group for users who have attribute A or attribute B, who don’t have attribute C, or other more complex queries.
- Are an intersection, not a union. A user must have all the attributes in the group to be added to the group.
Reporting groups
Section titled “Reporting groups”Reporting groups use reporting hierarchy to define membership.
Reporting groups define users who have the same manager, or are part of the same organization. There are two types of reporting groups: a user’s direct reports only, and a user’s organization, including their direct and indirect reports. The manager themselves is not included in the reporting group.
Like attribute-based groups, reporting groups automatically update when managers change. You can’t manage reporting group membership manually.
Team groups
Section titled “Team groups”Team groups are defined manually, by adding or removing users from the group.
Team groups define groups of users who work together. For example, a group “Go to market team” would include all users who in the Sales department, but also those in Marketing, Product, or other departments.
You manually add or remove users from a team group.
Integrations
Section titled “Integrations”Integrations connect Oblique to the external systems your organization uses. Oblique reads users, user attributes, accounts, and resources from integrations into Oblique, and writes entitlements back.
Each integration has a status, which shows whether it’s up to date with Oblique: Synced, Pending, Error, or Paused.
Accounts
Section titled “Accounts”An account is a profile in an integration with its own access, such as a GitHub organization member or a Slack user. An account may or may not map to a user in Oblique.
Oblique matches accounts to users based on their email, including secondary emails. Users can have several accounts in the same integration. Some accounts, such as service accounts, may not be mapped to any users.
Resources
Section titled “Resources”Resources are objects in an integration whose access Oblique lets you see and manage.
Integrations always have at least one resource, which is the representation of the integration itself, but may have multiple resources if this is supported in the integration.
Roles are sets of permissions that exist on a resource, which can be assigned to a user, group, or team.
Entitlements
Section titled “Entitlements”Entitlements define that a user, account, or group can access a resource. Each entitlement represents a unique relationship between a subject, of one or many users, accounts, or groups, and a resource.
An entitlement is a specific link between a subject and a resource. A user, account, or group has access to a resource when they have one or more entitlements that grant access to that resource. Using groups to create entitlements lets you grant access more efficiently, and manage access for multiple subjects at the same time.
A user, account, or group with a particular role has access to the resources associated with that role.
When Oblique imports an entitlement from an integration, the entitlement is tied to the account that holds the access, which may or may not be matched to a user. Oblique can only create entitlements to users and groups.
Entitlements function as positive grants: they grant access to something rather than deny access. Oblique doesn’t support deny entitlements.
Expiration
Section titled “Expiration”Entitlements can be indefinite or expire. Expiry can be set based on a time period (e.g., 30 days), or set to a specific date.
When an entitlement expires, Oblique automatically revokes it.
Giving a user access to a resource directly creates an anti-pattern because this approach proves harder to understand, maintain, and audit. Instead, give users temporary access, and grant indefinite access to groups.
Requests
Section titled “Requests”Changes to access controls are made through requests. A request can be creating or revoking an entitlement, and creating or updating a group. A user might request access to a resource, but they might also request to join a team group, granting them access to the team’s resources.
Request states
Section titled “Request states”Requests can be in one of the following states:
- Open: The change request is open. It has not been applied or closed. A request can be open with all, some, or no checks completed.
- Applied: The change request has been applied.
- Closed: The change request has not been applied, and has been closed by the requester or a reviewer. Oblique will also automatically close a request if it is obsolete. The request is maintained in Oblique for audit purposes, and can no longer be edited.
Checks
Section titled “Checks”Requests need to pass checks before they can be applied. Checks are specific requirements which need to be met before a request can be applied, such as an approval from a specific user or group, or verification of a specific condition. Requests might also have no checks or be auto-applied.
Once a request passes all checks, it’s automatically applied.
Reviews
Section titled “Reviews”An access review is a point-in-time record of who had access to each app in your environment, a decision to approve, remove, or change that access, and any remediation needed based on those decisions. These are often required for compliance frameworks such as SOC 2, where auditors look for evidence that access reviews are regularly completed.
Each access review defines the scope of apps to be reviewed. For every app in scope, Oblique captures the set of accounts in the app, with their access. This is taken directly from the app where there is a direct integration, or else can be manually added by uploading a screenshot or pasting a user list. A reviewer then makes a decision on every account, to approve the access, remove it, change it, or mark the account out of scope. Accounts you decided to remove or change become remediation items.
Each review is independent. Once a review is completed, it cannot be edited. A new review starts from the previous review’s scope, but captures its own accounts and holds its own decisions, so an earlier review is never changed by a later one.
Management
Section titled “Management”Your Oblique tenant has one or more admins, who can make changes in Oblique, including make access changes. Oblique’s audit logs record all changes made in Oblique, including access changes, for audit purposes.
Owners
Section titled “Owners”Resources and team groups have owners, who can help with managing access to those resources and teams. Owners can include users or groups. Owners help identify who manages each resource or team, and help scale access management by delegating responsibility for access changes to those with more context.
By default, Oblique admins are owners of all objects, whether additional owners exist.
Deletion
Section titled “Deletion”When you delete a group, user, or resource, Oblique automatically revokes all associated entitlements and doesn’t permit creating new entitlements.
Objects are soft deleted in Oblique, so that you can still see them in audit logs. You can’t grant access to deleted objects, or restore them.
Recommendations
Section titled “Recommendations”Recommendations are suggestions from Oblique that help admins simplify entitlements so they’re easier to understand and maintain.
Oblique aims to help you move toward more maintainable access over time. Once you understand the access in your environment, the next step is simplifying it — and recommendations are how Oblique surfaces specific opportunities to do that. For example, if a user has access both directly and through a group, the direct entitlement can be removed: the user keeps the same access, but it’s now clear they have it because of their group membership.
Each recommendation is a concrete, deterministic change that reduces complexity without altering who has access. Recommendations are not security or risk-based suggestions to reduce access, they’re only about making access easier to reason about.