2026.10.3 — 2026-10-01
Breaking
Sign-in providers and metric history reads for plugins (#162) (dc500eee)
- docs(openspec): design plugin sign-in providers and metric history reads
Design, sharpened specs and ordered tasks for change 15b, with ADR-0153 (plugins sign users in through declared credential providers that answer with an identity; verified plugins only; Studio revalidates subjects; second factors cover every password account) and ADR-0154 (plugins read metric history as a named user through the metrics read API's checks).
- feat(plugins): let plugins read metric history as a named user
A plugin can now read queue, cluster and plugin-metric history through the new MetricHistory bean by naming the user it acts for. The read runs as that user's account as it stands now, with the same cluster check, plugin-metric permission, retention clamp and point cap as the REST API, and a user who is unknown, disabled or without access gets the answer for a cluster that does not exist. MetricQuery and the MetricViews records are now plugin API.
- feat(plugins): let a trusted plugin offer a username-and-password sign-in
A plugin can declare identityProviders in plugin.json and expose one PluginCredentialProvider bean per provider. The provider appears on the login screen like any other credential provider and answers with who the credentials identify; Studio keeps throttling, account lockout, second factors, the session, the audit trail and the provider's group mappings. A call that throws or takes longer than 5 seconds fails like a wrong password and shows in operational health (pluginSignIn) until the next call succeeds.
Only a plugin signed by a trusted key may sign users in: the allowance for unverified plugins does not cover it, installing or updating a plugin that adds a sign-in needs the new confirmation signin-added, and a plugin whose key is removed keeps running but stops signing anyone in at once.
- feat(plugins): end the access of users a plugin's sign-in no longer vouches for
Every five minutes Studio asks each running, trusted plugin sign-in which of its users it no longer vouches for, using the optional noLongerValid method of PluginCredentialProvider. For each user it names, Studio ends their sessions, revokes their API tokens, forgets their trusted devices and audits IDENTITY_REVOKED. The account stays enabled, so a user restored at the source signs in again. A provider that does not implement the method changes nothing, and revocation pauses while the plugin is stopped.
- feat(auth)!: require a second factor of every account that signs in with a password
A role that requires a second factor now applies to every account whose provider checks a password: local accounts and the users of a plugin's sign-in. Users of a redirect provider such as OIDC are still not challenged. A plugin sign-in user holding such a role enrols an authenticator app or passkey at their first sign-in and then signs in with their password and a code, and the Users and Account screens treat them like local users.
Added
Sign-in providers and metric history reads for plugins (#162) (dc500eee)
- docs(openspec): design plugin sign-in providers and metric history reads
Design, sharpened specs and ordered tasks for change 15b, with ADR-0153 (plugins sign users in through declared credential providers that answer with an identity; verified plugins only; Studio revalidates subjects; second factors cover every password account) and ADR-0154 (plugins read metric history as a named user through the metrics read API's checks).
- feat(plugins): let plugins read metric history as a named user
A plugin can now read queue, cluster and plugin-metric history through the new MetricHistory bean by naming the user it acts for. The read runs as that user's account as it stands now, with the same cluster check, plugin-metric permission, retention clamp and point cap as the REST API, and a user who is unknown, disabled or without access gets the answer for a cluster that does not exist. MetricQuery and the MetricViews records are now plugin API.
- feat(plugins): let a trusted plugin offer a username-and-password sign-in
A plugin can declare identityProviders in plugin.json and expose one PluginCredentialProvider bean per provider. The provider appears on the login screen like any other credential provider and answers with who the credentials identify; Studio keeps throttling, account lockout, second factors, the session, the audit trail and the provider's group mappings. A call that throws or takes longer than 5 seconds fails like a wrong password and shows in operational health (pluginSignIn) until the next call succeeds.
Only a plugin signed by a trusted key may sign users in: the allowance for unverified plugins does not cover it, installing or updating a plugin that adds a sign-in needs the new confirmation signin-added, and a plugin whose key is removed keeps running but stops signing anyone in at once.
- feat(plugins): end the access of users a plugin's sign-in no longer vouches for
Every five minutes Studio asks each running, trusted plugin sign-in which of its users it no longer vouches for, using the optional noLongerValid method of PluginCredentialProvider. For each user it names, Studio ends their sessions, revokes their API tokens, forgets their trusted devices and audits IDENTITY_REVOKED. The account stays enabled, so a user restored at the source signs in again. A provider that does not implement the method changes nothing, and revocation pauses while the plugin is stopped.
- feat(auth)!: require a second factor of every account that signs in with a password
A role that requires a second factor now applies to every account whose provider checks a password: local accounts and the users of a plugin's sign-in. Users of a redirect provider such as OIDC are still not challenged. A plugin sign-in user holding such a role enrols an authenticator app or passkey at their first sign-in and then signs in with their password and a code, and the Users and Account screens treat them like local users.