Use cases

Enterprise controls

Separation of duties that a system enforces rather than a policy document describes.

The problem

The person who configures the controls should not be the person the controls constrain. In most systems the administrator is both.

Without Bengar

• A superuser role that can do everything, used daily.
• Approval as a status field somebody with database access can set.
• An audit trail the audited party can edit.

With Bengar

• ADMIN that cannot approve, cannot author policy and cannot register permits.
• Approvals signed by a key held outside the application, by a person who was present.
• Self-approval and duplicate-approver refusals enforced at the route.
• An append-only trail, anchored so it can be checked externally.

The flow

1. Roles are separated per operation, not per person.
2. A decision needing a person opens an obligation.
3. The approver signs a statement of exactly what will happen.
4. The record is anchored and can be proven later.

Components used

Console · Approvals · Custody · Audit · Proofs

Example

// The role table, as the Gateway enforces it.
"api-key.create":   ["ADMIN"]
"policy.activate":  ["POLICY_AUTHOR"]   // not ADMIN
"permit.register":  ["PERMIT_ISSUER"]   // not ADMIN
"approval.decide":  ["APPROVER"]        // not ADMIN

Security properties

Try it →