Platform Policies
What this screen is for
Platform Policies is where the platform administrator of an installation sets the cryptographic policies that belong to the deployment as a whole, and sees and changes what each tenant carries. The Policies tab has two sections: Deployment Policies, four cards for Algorithm Availability, Algorithm Rotation, Key Lifecycle and TSA Usage; and Per-Tenant Policies, one row per tenant with its algorithm, rotation and lifecycle template and, while the deployment delegates time-stamping, its TSA selection. The Cache Operations tab pushes policies to the cache the crypto service reads.
Every policy exists at two levels. What you set here is the deployment's; a tenant either follows it or carries a policy of its own, set on its Policies screen or from the table here. Its labels are shown in English whatever language the console is set to; only the refusals are translated.
What must exist first
The screen is offered in system context only; opening it while a tenant is assumed returns you to that tenant's dashboard. Its navigation entry appears for anyone holding a permission to read the deployment policies, to read every tenant's policies, or to read or write the deployment lifecycle policy.
- The Algorithm Availability and Algorithm Rotation cards each read the deployment policy with its own read permission. Without it the card still renders and names
DEFAULT, whatever template is really stored. - Change template and Reset are offered on both cards to everyone. The server requires the write permission for the one and the delete permission for the other, and a refusal shows You don't have permission to perform this action. Browsing templates needs the permission to read policy templates.
- The Key Lifecycle card appears only with the permission to read the deployment lifecycle policy; TSA Usage only with the permission to read the deployment TSA policy, and without the write permission its control is disabled under This policy is managed by your platform administrator.
- The Per-Tenant Policies table needs the permission to list tenants; without it the table reads No tenants yet. Changing a cell needs the tenant write permission for that policy.
Decisions you make here
Choosing the deployment algorithm and rotation templates
Change template opens the same catalog the tenant screen offers, one card per template with a Currently applied mark, Preview details and Apply. Applying stores the template as the deployment policy: its content is resolved from the template on every read, so a template the platform ships is never copied into the policy. Reset stores DEFAULT as the deployment policy, resolved from the template on every read like any template you apply.
Which tenants it reaches is the decision that matters. The crypto service resolves a tenant's own policy first and falls back to the deployment policy only when the tenant has none.
On an installation whose policies are not locked, every tenant has an algorithm and a rotation policy of its own from the moment it is created: a tenant created with a template carries that template, and a tenant created without one — the dialog's Follow deployment policy option — is bound to the deployment policy — to the deployment's template when the deployment is on a template, or to a snapshot of the deployment's effective policy when the deployment policy was written by hand.
A tenant that pressed Follow deployment policy on its Policies screen is in the same state. A bound tenant follows the content of the template it is bound to, so editing that template reaches it; moving the deployment to a different template does not re-bind it.
A change here — Change template, Reset, or a Sync from Cache Operations — is written to the policy cache and published to the crypto service before the server answers, and the crypto service drops every policy it holds in memory when it receives it. The next operation of every tenant that follows the deployment policy is evaluated under the new one; nothing waits for the policy cache lifetime to expire. Only a tenant that carries a template or a hand-written policy of its own keeps its own policy.
The deployment policy is a ceiling on what a tenant may pick. The server compares the policy a tenant would have with the deployment's effective policy, dimension by dimension, and refuses a tenant template or policy that admits anything the deployment does not, whether the deployment policy is a template or written by hand.
A deployment dimension left empty restricts nothing on that dimension. Whether a tenant may change its own policy at all is decided by the per-tenant override flag on the tenant's detail, and by that alone: locking the deployment's policies fixes the deployment's own policy and does not withdraw a tenant's flag.
When a template is refused as a narrowing
A template can be refused with Deployment policy narrowing affects N tenant(s): names. The server compares the effective policy every tenant has — the content of its template, or its own values — with the effective policy the deployment would have under the template you chose, dimension by dimension, and lists exactly the tenants whose effective policy admits something the new deployment policy would not.
A dimension the new deployment policy leaves empty restricts nothing, so a tenant is never reported for it. A tenant bound to the template you are applying is never a conflict; a tenant bound to the deployment's previous template is one whenever the new template is narrower, because a tenant is never narrowed without you seeing it. Nothing is stored while the list is shown; resolve it by moving the listed tenants to a narrower template from the table below, or choose a wider template here.
What a tenant takes from here when it follows the deployment policy
Follow deployment policy on a tenant's Policies screen does not delete the tenant's policy: it binds the tenant to the deployment policy as it is set here. While the deployment is on a template, the tenant is bound to that template and its card names it; while the deployment policy is written by hand, the tenant receives a snapshot of the deployment's effective policy as a custom policy of its own.
In both cases the tenant's effective policy equals the deployment's at its next operation, and the tenant's row is never left with every dimension empty. The tenant's reset is refused when this screen holds no deployment policy for that card, and when you have not let the tenant change its policies: the reset would undo the policy you chose for it, so the tenant's screen does not offer it then.
What Reset does to the cache
Reset on either card stores DEFAULT as the deployment policy, writes the resolved policy to the policy cache and publishes the change to the crypto service before answering; it removes nothing from the cache. A tenant that follows the deployment policy is evaluated under DEFAULT from its next operation.
Setting the deployment lifecycle ceiling
The Key Lifecycle card only names the template in effect; Open editor takes you to the deployment editor, where the ceiling every tenant's lifecycle policy is checked against is set:
Choosing the deployment TSA usage mode
The TSA Usage card is a three-way control, DISABLED, OPTIONAL and REQUIRED, applied as soon as you click. DISABLED and REQUIRED override every tenant: no tenant can stamp under the first, and under the second every signature is stamped, so a tenant with no usable time-stamping connection cannot complete one. OPTIONAL delegates the decision to each tenant, and a tenant that has not chosen does not stamp.
Moving to DISABLED while tenants are stamping first shows how many will stop, and Disable stamping confirms; their selections are kept and apply again when you return to OPTIONAL. A move to REQUIRED or OPTIONAL is refused when a tenant, or the deployment default, would be required to stamp with no usable connection; the refusal states the count, and Apply anyway applies the change with those tenants unable to complete a timestamped signature until a connection is usable.
Assigning a tenant's policies from the table
Each Algorithm and Rotation cell opens the template catalog for that tenant, and applying writes the tenant's own policy; the platform administrator is not subject to the tenant's override flag. A cell reads as a lock badge for a tenant that carries no policy of its own on a locked installation, because that tenant follows the deployment policy; the lock is set when the installation is created and cannot be changed here. A tenant that carries its own policy keeps its own cell, locked installation or not.
The Lifecycle cell opens that tenant's lifecycle editor, which is never locked. The TSA column exists only while the deployment mode is OPTIONAL; its cell sets the tenant to ON, OFF or inherit, and is the first place a tenant's selection can be made.
Pushing or clearing the policy cache
Cache Operations has three cards, each with its own permission. Sync Policies rewrites the deployment and tenant algorithm and rotation entries, for every tenant or for one tenant by identifier, optionally clearing first, and then tells the crypto service to drop the policies it holds in memory, so the rewritten entries are read on the next operation.
The card reports the sync as completed only when the entries were written and the invalidation was published; a sync whose publish failed is reported as failed. Cache Status reads the cache. Clear Cache with scope All removes every policy entry from the cache, the lifecycle and time-stamping projections included, and publishes the same invalidation; the crypto service re-derives those from the platform on its next read, and reads the algorithm and rotation entries again only after a Sync or a save.
How it relates to other screens
Each tenant sees the effect of this screen on its own Policies hub, where, when you have let it change its policies, it can pick a template of its own or reset to the deployment's:
The deployment lifecycle policy bounds tenants cell by cell rather than dimension by dimension, and it has its own editor:
The algorithm catalogue a tenant sees is the platform catalogue filtered by its effective algorithm policy; the platform view of that catalogue can be filtered by the deployment policy you set here: