Who administers an organization

An organization has two kinds of authority, and they answer different questions.

A role is an application’s own vocabulary about its own data: who reads the member register, who publishes an article. You declare roles in .mtd, the compiler checks them, and the access matrix covers them.

The tenant administrator flag is the organization’s authority over its logins: who may add one, disable one, or end its sessions. It is a flag on a login, and it is never a role.

The flag grants nothing inside an application

The flag decides who administers the organization. It decides nothing about the data inside an application.

An administrator is not automatically anybody inside an application

A tenant administrator with no role in your application is anonymous in your application. They cannot read the member register, and they cannot open a page that a role protects.

One property test covers the whole access matrix. For every route of every application and every role, the decision with the flag set equals the decision with the flag clear.

An administrator who needs an application’s data needs a role in that application. Roles can be granted or revoked separately for each application on the logins page. Each save records an admin.authority event kept forever, naming the administrator, target login, application, and role.

The cost is visible on purpose. An access that an administrator takes leaves a permanent record. An invisible bypass would cost nothing and would leave nothing to find.

Use the same controls to grant yourself a role. Your tenant administrator flag alone never grants application access.

Why the authority is not a role

A role name means what one application means by it. admin means “the whole calendar” in one application and “the editorial lead” in another. An organization-wide role vocabulary would merge two unrelated meanings and call the result a privilege.

tenant_admin is therefore a reserved role name that no application may use. The compiler refuses a declaration of it, and it refuses an access: rule that names it.

An application that could name the word would gate its own pages on the authority of the organization that installed it. Who administers an organization is that organization’s answer, not an application’s.

See Reserved names for the whole reserved set.

Where the flag lives

The flag is a column on the login in your own tenant database. It is resolved in the same query that resolves the rest of the identity. “Who is this person” and “may they administer the organization” therefore have one derivation and one answer per request.

Your application cannot read the column, because no application can read the engine’s own tables.

How the first administrator exists, and why the last one cannot go

matterdata install makes its first login a tenant administrator. Before install there is nobody to ask; after it there is somebody to ask.

The last administrator cannot be demoted or disabled. An organization with none has no repair inside its own database: there is no higher authority in the file, and the only way back is somebody with shell access to the server running matterdata grant-admin.

The rule is a condition of the statement that changes the row, not a check before it. Two administrators who demote each other at the same moment therefore cannot both succeed.

Manage logins for your organization shows both acts on the page, and the two commands that set the flag on a tenant file.

Why the page answers 403 and not 404

A record that a person may not see answers 404, because 403 would confirm that the record exists. The administration page is not a record. Every organization has one, and its existence is not a secret. A person who gets 403 here is a colleague who is signed in with the wrong authority, so the ordinary refusal applies and no new refusal shape enters the engine.

What the flag cannot express

The flag is organization-wide. “They may manage the calendar’s logins and nothing else” is not expressible, and an authority matrix is not proposed.

The flag is also the only tenant-wide authority. It does not make its holder an operator of the server, and it gives no access to another organization’s database.