Delegated administration

Delegated administration usually means one thing when a customer asks for it: an administrator whose powers stop at a boundary. The manager of the Cork office who can reset passwords for Cork and nowhere else. The contractor who administers the servers but not the people. This article explains what Qorionix actually provides against that request, and the honest answer is narrower than the name suggests.

What does exist is a thinner mechanism that shares the name, is genuinely useful for one particular job, and is worth understanding on its own terms rather than as a disappointing version of the other thing.

What actually exists: a role name

Three administrative actions in Qorionix carry an extra condition on top of the ordinary permission check. Adding or changing an organisation member, editing a role, and configuring single sign-on all require that the caller's role is named exactly admin or delegated_admin. It is a comparison of the role's name, not of what the role holds. A role called Access reviewer that holds members.write is still refused, with HTTP 403 and the message action requires elevated delegated role.

So delegated_admin is the one name other than admin that opens those three doors. It is not created for you: a new organisation gets admin, member and viewer, and that is all. If you want one, you create a role and name it — exactly, in lower case, with the underscore. The matching is case-sensitive, so Delegated_Admin matches nothing and receives nothing.

Name it correctly and something useful happens. The database trigger that hands the built-in roles their default grants also recognises this name, so the role is created already holding a considered set of identity-administration permissions:

The pattern is consistent and it is the interesting part of the design: read and write, never delete, and never an action that issues a credential. Somebody who curates your identity configuration can do the day-to-day work without being able to remove a control or hand out a key.

What a delegated administrator cannot do

Setting aside what you choose to grant, three limits apply regardless.

• Scope is the whole organisation. There is no way to say these users or these machines. Whatever you grant applies to every object of that kind in the tenant. If you grant users.write, you have granted it over everybody.
• Editing a role needs a fresh second factor every time. roles.write, users.write and organizations.write all require a step-up, and three more — api_keys.write, members.write and sso.write — require one unless the device and network are both recognised, which in practice means almost always. The console handles this now: a prompt headed Confirm your identity appears, takes a one-time code or a recovery code, and retries. What it means for a delegated administrator is that they need an enrolled second factor of their own, and that a script holding their API key cannot perform any of the six. See Step-up authentication.
• Time-boxing is not available. The unused resource-scoped grant model has an expiry field. The role mechanism has nothing equivalent, so a delegated administrator holds their access until you change it. Put a review date in your own calendar; the product will not remind you.

There is also a set of surfaces that no role restricts at all. Groups, lifecycle rules, directory synchronisation settings and the console's branding are authenticated and locked to your own organisation, but carry no permission check — so any member can use them whatever role you gave them. Restricting somebody's role does not restrict those. Groups and automatic membership explains the consequences.

How to check what someone can actually do

The recurring theme of this article is that names are claims and lists are facts. Before you rely on a boundary, verify it. Four steps, in this order, and none of them takes long.

1. 1

   Read the permission list, not the role name

   Open Identity → Roles, select the role, and read every permission on it. A role called Read only support may hold writes somebody added last year. This is also where you catch the built-in over-grants described in Building a role that grants exactly enough — in particular pam:credentials.read appearing on member or viewer, which it should not.

2. 2

   Check the membership, not the person

   Access comes from the single role attached to their membership of this organisation. Confirm which role that is. A person can look like a viewer in one organisation and hold admin in another, and the two facts do not interact.

3. 3

   Have them try it, in their own session

   The only complete test. Ask them to attempt the things they should be able to do and one thing they should not, and to tell you what happened. A refusal reads insufficient permissions with HTTP 403; a name-based refusal reads action requires elevated delegated role, also 403; and a request for a second factor arrives as a Confirm your identity prompt rather than an error, carrying the code step_up_required underneath. Those three mean different things — a missing permission, a role with the wrong name, and a control working correctly — and knowing which one they saw usually tells you the answer immediately.

4. 4

   Read the audit log a week later

   Filter to that person and read what they actually did, against what you expected. This is the check that catches the permission you granted for one task and forgot about. Note that there is no export from the audit log, so this is a reading exercise rather than a report you can file.

What to do instead

If what you need is genuinely a boundary — this administrator may not touch that part of the business — the options today are limited and it is better to hear them plainly than to configure something that looks like a boundary and is not.

Split by job, not by scope

Build separate roles for separate functions — one that administers identity, one that administers privileged access, one that reads compliance evidence — and give each person exactly one. You get separation of duties, which is most of the value, without pretending to have separation of territory.

Use fewer administrators

The most effective control available and the least fashionable. Two administrators, one of them your backup, is the recommendation in Who can see and do what and it is still the right answer. Every additional administrator is another account that hands over the whole organisation if it is stolen.

Separate organisations, with a caveat

A genuine hard boundary is a separate Qorionix organisation, because permission checks never cross one. It is a real answer for a group with independent subsidiaries. Read the multi-organisation limitation in Who can see and do what before you commit: a person who belongs to two organisations currently loses access to some features, so plan on one account per organisation per person.

We would rather set this out than let you build a delegation model on a mechanism that does not enforce what its name implies. Resource-scoped delegation is worth building and it is not built. When it is, it will be documented here with the same directness as everything above.

What to do next

1. The permission model — what a permission is, and the boundaries that do not currently hold.
2. Building a role that grants exactly enough — three worked scenarios and the over-grant to check for.
3. Who can see and do what — the built-in roles and the recommendation on how many administrators to have.