Authentication Policy
What this screen is for
This screen decides two things for the whole deployment: How platform administrators sign in, and What every tenant may admit when its members sign in. It is reached from Access & Identity → Authentication policy.
Every tenant can only restrict what this screen allows, never widen it. What is in effect is shown as the platform composes it; the screen derives nothing on its own.
What must exist first
- The platform context.
- The permission to read the platform authentication policy, held by every built-in platform role. Changing anything needs the permission to manage it, held by the platform super administrator only; without it every control is read-only.
- For a platform sign-in through an identity provider: a deployment
OIDCorSAMLprovider, enabled and approved for platform sign-in on the Identity Federation screen.
Decisions you make here
How platform administrators sign in
When platform administrators sign in locally on a deployment your organisation operates, they do so with a passkey that verifies the person, or with their password and an authenticator-app code, whatever this screen allows the tenants, and a passkey is offered first where the console's address supports one. On a deployment ANKATech operates they sign in with a phishing-resistant passkey only, and requiring phishing resistant cannot be removed. You choose where they may sign in:
- Here only: local sign-in only, with a passkey or with password and authenticator app.
- Here or through the identity provider: local sign-in, or an approved deployment provider.
- Through the identity provider only: an administrator linked to an approved provider signs in only through it. The administrators designated for break-glass access enter through Emergency access with their security keys.
Either of the last two needs an approved provider, and the third also needs a ready break-glass administrator; otherwise the change is refused with the reason. The Break-glass access panel shows whether one is ready, each designated administrator with their security keys and last break-glass sign-in, and recommends a second key for one holding a single key. You can also require passkey properties, added to the ones every tenant requires. Only a passkey can hold one, so while a property is required, a platform administrator signs in locally with a passkey that holds it.
Once the console's host name works and every platform administrator holds a passkey on it, require phishing resistant here so password and authenticator app no longer admit them. Until then platform health and the setup status report a finding recommending it. A change that would leave a platform administrator with nothing it accepts is refused: each one registers a passkey first. An identity provider is approved for platform sign-in only when you attest that it enforces phishing-resistant multi-factor authentication.
What every tenant may admit
Choose the sign-in methods a tenant may admit, Passkey and Password and authenticator app, and the passkey properties every tenant requires. A tenant that has chosen nothing signs its members in exactly as allowed here.
A change that would leave a tenant with no way for its members to sign in locally is refused, naming those tenants: change their own settings first. Admitting no method, or requiring a property without admitting passkeys, is refused too.
A deployment with one tenant
When the deployment holds a single tenant besides the platform, that tenant's sign-in settings are shown and edited on this screen as well, because one organisation decides both. They stay on the tenant's own settings too.
Audit
Every change is written to the audit trail with the values before and after.
How it relates to other screens
Approving a provider for platform sign-in is done on the identity provider itself:
Each tenant narrows what this screen allows on its own settings, and restricts single members on its users screen:
The rest of the sign-in configuration is the group this screen sits in: