Recipes

Wildcard Admin

Bootstrapping a safe global administrator.

Situation. Valmont's platform team needs one bootstrap administrator who can do everything, everywhere, without holding a role in each of dozens of organizations.

The wildcard row

A single global rule with both activity and view NULL:

INSERT INTO morbac.global_rules (user_id, activity, view, context_id, modality)
VALUES ('99999999-9999-4999-8999-999999999999',   -- the admin account
        NULL, NULL,
        (SELECT id FROM morbac.contexts WHERE name = 'always'),
        'permission')
ON CONFLICT DO NOTHING;

Proof

-- any org, any activity, any view
SELECT morbac.is_allowed('99999999-9999-4999-8999-999999999999',
    (SELECT id FROM morbac.orgs WHERE name = 'Clinique Valmont Sud'),
    'delete', 'invoices');                                  -- true
 
-- even with no org at all (global resources)
SELECT morbac.is_allowed('99999999-9999-4999-8999-999999999999',
    NULL, 'read', 'orgs');                                  -- true
 
-- and nobody else inherited anything
SELECT morbac.is_allowed('22222222-2222-4222-8222-222222222222',
    NULL, 'read', 'orgs');                                  -- false

Doing it safely

One row, real admins only. The wildcard crosses every organization, including future tenants. If the deployment is multi-tenant, this is a platform operator, never a customer admin.
Customer admins get subtree rules instead: an admin role at the tenant's root org with scope subtree gives everything inside the tenant and nothing outside; see org hierarchies.
It is still overridable. A prohibition at higher priority beats the wildcard (priority NULL = 0), which is exactly how an emergency lockout works:

INSERT INTO morbac.global_rules (user_id, activity, view, context_id, modality, priority)
VALUES ('99999999-9999-4999-8999-999999999999', NULL, NULL,
        (SELECT id FROM morbac.contexts WHERE name = 'always'),
        'prohibition', 1000)
ON CONFLICT DO NOTHING;
 
SELECT morbac.is_allowed('99999999-9999-4999-8999-999999999999',
    NULL, 'read', 'orgs');                                  -- false: locked out
 
DELETE FROM morbac.global_rules
WHERE user_id = '99999999-9999-4999-8999-999999999999' AND modality = 'prohibition';

Audit it. Enable the built-in audit trigger on global_rules so every change to wildcard powers leaves a trail:

SELECT morbac.enable_audit('global_rules');

The wildcard row

A single global rule with both activity and view NULL:

INSERT INTO morbac.global_rules (user_id, activity, view, context_id, modality)
VALUES ('99999999-9999-4999-8999-999999999999',   -- the admin account
        NULL, NULL,
        (SELECT id FROM morbac.contexts WHERE name = 'always'),
        'permission')
ON CONFLICT DO NOTHING;

Proof

-- any org, any activity, any view
SELECT morbac.is_allowed('99999999-9999-4999-8999-999999999999',
    (SELECT id FROM morbac.orgs WHERE name = 'Clinique Valmont Sud'),
    'delete', 'invoices');                                  -- true
 
-- even with no org at all (global resources)
SELECT morbac.is_allowed('99999999-9999-4999-8999-999999999999',
    NULL, 'read', 'orgs');                                  -- true
 
-- and nobody else inherited anything
SELECT morbac.is_allowed('22222222-2222-4222-8222-222222222222',
    NULL, 'read', 'orgs');                                  -- false

Doing it safely

One row, real admins only. The wildcard crosses every organization, including future tenants. If the deployment is multi-tenant, this is a platform operator, never a customer admin.

Customer admins get subtree rules instead: an admin role at the tenant's root org with scope subtree gives everything inside the tenant and nothing outside; see org hierarchies.

It is still overridable. A prohibition at higher priority beats the wildcard (priority NULL = 0), which is exactly how an emergency lockout works:

INSERT INTO morbac.global_rules (user_id, activity, view, context_id, modality, priority)
VALUES ('99999999-9999-4999-8999-999999999999', NULL, NULL,
        (SELECT id FROM morbac.contexts WHERE name = 'always'),
        'prohibition', 1000)
ON CONFLICT DO NOTHING;
 
SELECT morbac.is_allowed('99999999-9999-4999-8999-999999999999',
    NULL, 'read', 'orgs');                                  -- false: locked out
 
DELETE FROM morbac.global_rules
WHERE user_id = '99999999-9999-4999-8999-999999999999' AND modality = 'prohibition';

Audit it. Enable the built-in audit trigger on global_rules so every change to wildcard powers leaves a trail:

SELECT morbac.enable_audit('global_rules');