Principles

We’ve built Oblique around five core principles that make access controls more understandable and manageable. These may be different from what you’re familiar with in existing systems.

• Requests: Access changes are made through a request workflow
• Justifications: Access changes should have justifications
• Expiry: Expiry makes exceptions easier to manage
• Ownership: Resources and groups have owners to manage them
• Soft deletion: Objects are soft deleted to preserve audit logs

Requests

To make changes to access controls at scale, individual users need to be able to make or request access changes. Often, this stops at users making requests for specific resources, but that’s not enough. Users also need to be able to request access for their teams or reports, create teams, or change team membership. All these changes are made through requests.

Making changes through a request workflow lets you preview the impact of a change before making it, verify that requirements are met, and keep a record of who made the change and why.

Although all changes are made via a request, we don’t recommend requiring all changes to have explicit approvals. Rather, changes can be automatically applied based on the checks you set for each request, and only some will require approvals.

Justifications

You need context to understand why a user or group has access to a resource. As part of every access change you make in Oblique—whether that change is direct or indirect—you can provide a justification for that change.

Most justifications can be inferred, so users shouldn’t need to provide them. For example, if a user is added to a team, the justification is their team membership. If a user’s role changes, the justification is the role change. Where a justification can’t be inferred, it should be specific about the business need.

That justification is stored in the audit log. When you review existing access controls as part of user access reviews, or when you review changes to access controls over time, you can understand why these changes happened.

We recommend that you only require justifications where they can’t otherwise be inferred.

Expiry

Not all access controls need to be permanent; in fact, ad hoc requests are often temporary. In Oblique, you can set an expiry date for entitlements. When the expiry date is reached, Oblique will automatically revoke the entitlement.

This helps “clean up” access controls automatically over time: access that’s no longer needed expires on its own.

We recommend that as a general principle, individual access to resources should expire, as this is an anti-pattern, so an exception that shouldn’t be long-lived. For any long-lived access, create a group and grant it access instead.

Ownership

To scale management of access controls, you need to share responsibility for access changes by delegating authority to those with more context. In Oblique, each resource and group has owners, and you can assign this ownership to a user or group. By default, Oblique admins are the owners of all resources and groups.

When you assign ownership, you’re saying that the user or group is responsible for maintaining that object. Having an owner is useful when you need to understand who is responsible for a particular resource or group, audit its access, or make changes to access. This also helps you spread the responsibility of managing access controls from the IT and security teams to individuals who might have more context.

We recommend defining owners for all objects, with at least two users or a group for each object. Having multiple owners is important so that if someone leaves the organization or is unavailable, it’s clear who else is responsible.

Soft deletion

When you remove a resource, group, or user, it is soft deleted in Oblique. When you soft delete an object, it’s no longer available for granting new access, but it stays in the audit log. Oblique’s audit logs are a record of all changes made to your access controls over time.

This lets you review what changes happened over time, in context with what the object’s state was at the time of the change. Soft deletion preserves the integrity and completeness of your audit trail.