KemalIdentity::Authz::Permission
One thing somebody may be allowed to do.
A permission is an action, not a resource and not a role: invoices.refund, not
admin and not invoice_42. Roles are collections of these, and the thing a route asks
about is always the action — env.auth.authorize!("invoices.refund") still reads
correctly two years later when the roles that grant it have been reorganised twice.
Why there are no wildcards
No invoices.*, no prefix matching, no hierarchy. A wildcard grant is a grant of
permissions that do not exist yet: whoever holds admin.* today silently acquires
admin.billing.export_everything the day it is added, and nobody reviewing that pull
request sees a privilege change. Enumerating them is more typing and is the entire point
— the diff that adds a permission is the diff that decides who gets it.
Assurance is part of the permission, not the call site
minimum_assurance says how strongly somebody must have proved who they are before this
action is available at all. It lives on the permission because it is a property of the
action — refunding money needs a second factor wherever it is called from — and a rule
written at each call site is a rule that is missing at the call site somebody forgot.
Constants
Lowercase dotted segments. Restrictive on purpose: permission names end up in audit trails, log queries and config files, and a name that differs from another by an invisible character or a capital letter is a permission that reads as granted and is not.
Constructors
Instance methods
For whoever has to administer this. Roles get assigned by people who did not write the
code, and invoices.refund alone does not say whether it moves money.
How strongly the caller must be authenticated. Password by default rather than
Remembered: a session restored from a cookie proves possession of a stored token, not
the presence of the account holder, and that is too weak a basis for any deliberate
action.