[Design Discussion] Support for Account Locking, Disablement & Brute-Force Attack Protection

[yeshandev]

Related Feature Issue

#5073

Problem Summary

ThunderID has no account lifecycle management. An entity is either present and usable or absent, which leaves three gaps an operator hits immediately:

1. No brute-force protection. Repeated failed authentication against one account costs an attacker nothing.
2. No administrative off switch. There is no way to stop an account authenticating while keeping the record for audit and later restoration.
3. No way to contain a suspected compromise. When an account is believed breached, an operator needs to stop it and keep the remediation path open.

Architecture Overview

ThunderID's account access rules live in one identity governance service. Authentication, sessions, token issuance and flows ask this service whether access is allowed. An entity is a user, agent or application. A verifier checks a credential, such as a password or one-time password (OTP).

flowchart TB
 subgraph RUNTIME["Runtime path · depends only on providers"]
    direction LR
        AUTHN["Authentication<br>provider manager"]
        TOKEN["Token builder"]
        ACTOR["Actor provider<br>OAuth client funnel"]
        EXEC["Flow executors"]
        ADMINEXEC["Identity governance<br>executor · disable · enable · unlock"]
        REVEXEC["Criteria revocation and<br>session revocation<br>executors · existing"]
  end
    AUTHN --> PORT{{"IdentityGovernanceProvider"}}
    TOKEN --> PORT
    ACTOR --> PORT
    EXEC --> PORT
    ADMINEXEC --> PORT
    PORT -. default provider delegates to .-> GOV["Identity governance service"]
    SERVERONLY["Atomic authentication endpoints / DefaultAuthnProvider"] --> GOV
    GOV --> POLICY["Policy resolver"]
    GOV -- trusted state read --> ENTITY["Entity service"]
    GOV -- narrow state write --> ENTITY
    ENTITY -. "failure and credential-change callbacks" .-> GOV
    ENTITY --> STORE["Entity store"]
    STORE --> DB[("ENTITY table")]
    ADMINEXEC -- publishes the trusted plan --> REVEXEC
    REVEXEC --> CONTAIN["Revocation and<br>session services"] & MAILNODE["Email executor · existing"]

Loading

The provider interface lets the full server and embedded engine use the same access checks. The server wires its governance service through the default provider; an embedder can supply a provider. Services that only run in the full server can call governance directly.

Each check supplies the entity ID, the operation being attempted and, where relevant, the verifier. Governance decides which restrictions apply. Callers do not repeat state or policy rules.

States and actions

The current design has three public statuses:

Behaviour	ACTIVE	LOCKED	DISABLED
Cause	No active restriction	Repeated failed authentication	Administrator action
Stored in ENTITY.STATE	Yes	No; calculated from lock data	Yes
New sign-in	Allowed	Blocked for the locked verifier, or all verifiers under entity-wide locking	Blocked
Existing session reuse	Allowed	Allowed by default; optionally blocked under entity-wide locking	Blocked
New tokens and refresh	Allowed	Allowed by default; optionally blocked under entity-wide locking	Blocked
Self-service recovery	Allowed	Allowed	Blocked
Admin profile and credential updates	Allowed	Allowed	TBD
Credentials and assignments	Kept	Kept	Kept
Ends automatically	Not applicable	At expiry, unless configured without an expiry	No

The API calculates effective status in this order: DISABLED > LOCKED > ACTIVE. A disabled account can still have a lock underneath it. Admin enable removes the disable only; unlock clears automatic locks and their counters only. Neither action reverses the other.

Lock scope and policy

A verifier is not necessarily one credential field or delivery channel. Password, or any credential answer share the credential verifier; OTP has its own otp scope. These are the two lockable verifier scopes in this phase. Other sign-in methods still receive the disabled-account check.

Lock scope

Factor	Option 1: per-verifier lock	Option 2: entity-wide lock
Counter	One per verifier	One shared entity counter
Effect of repeated password failures	Blocks credential sign-in; other verifiers remain usable	Blocks all new sign-in methods
Impact on the account holder	Limited to the affected verifier	Can remove every sign-in route
Existing sessions and token issuance	Unaffected	Can be blocked by policy
Self-service recovery	Allowed	Allowed

Decision: support both (configurable); default to per-verifier. Under entity-wide locking, block_existing_sessions and block_token_issuance control the extra restrictions. Both default to false and have no effect under per-verifier locking. A lock never revokes sessions or tokens; these flags block their use at the relevant checks while the lock applies.

Lock policy

At this state, account-lock policies will be defined at the server level in deployment.yaml. In the future, once centralized policy management is introduced, account-lock policies should also be manageable through that framework.
Each entity category starts with a default policy. Verifier-specific settings override only the fields they explicitly define. When entity-wide locking is configured, the entity settings override the corresponding category defaults instead.

account_access:
  user:
    lock_granularity: verifier       # verifier or entity
    default:
      enabled: true
      threshold: 5
      failure_window_seconds: 900
      lock_durations_seconds: [300, 900, 3600, 86400]
      lock_decay_seconds: 86400
      disclose_hold_reason: never
    scopes:
      otp:
        threshold: 3
        failure_window_seconds: 600
        lock_durations_seconds: [300, 900]
        lock_decay_seconds: 3600
      entity:
        block_existing_sessions: false
        block_token_issuance: false
  agent:
    default: { enabled: false }
  application:
    default: { enabled: false }

This example matches the supplied policy defaults. The user default locks after five failures. Its failure count starts over after 15 minutes without a failure. Repeated lockouts last 5 minutes → 15 minutes → 1 hour → 1 day; the last duration repeats. After a day beyond the previous lock's end, the next lock starts at the first duration again.

A duration of 0 means no automatic expiry. Recovery through a completed recovery or admin unlock can still release it. lock_decay_seconds: 0 means lockout history does not decay with time.

Automatic locking is off for agents and applications in this phase; their credential-failure handling needs further work. Administrators can still disable and enable them. A future policy store can add rules by user type or other criteria through the policy resolver.

A held account uses the normal authentication-failure response. Hold reasons are hidden by default and controlled by server policy.

Administration and notifications

Lifecycle actions run as administration flows through IdentityGovernanceExecutor. Default flows provide disable and enable for users, agents and applications, plus unlock for users.

The default disable flow runs these steps:

Check permission → Set DISABLED → Revoke subject tokens/grants → End subject sessions → Send email

Governance owns the state change. The following flow nodes own revocation, session termination and notification. Access checks continue to enforce DISABLED even if a later step fails. Token revocation also depends on where tokens are validated; it does not promise instant removal of access everywhere.

Automatic lock notifications are deferred. A lock forms inside failed credential verification, which may return to the input prompt without running another flow node.

Storage and writes

Current Approach (Not decided):

Data	Current location
Administrative state	ENTITY.STATE: ACTIVE or DISABLED
Failure count and lock history	ENTITY.SYSTEM_ATTRIBUTES.accessState
Thresholds, durations and scope settings	Deployment configuration, read through the policy resolver
Public status	Calculated from state and lock data when the record is read

Example lock data:

{
  "accessState": {
    "credential": {
      "failureCount": 0,
      "lastFailedAt": "2026-09-10T10:04:12Z",
      "lockCount": 2,
      "unlockAt": "2026-09-10T10:19:12Z"
    }
  }
}

failureCount tracks failed attempts; lockCount selects the next duration. A timed lock is active while now < unlockAt; a no-expiry lock uses a reserved timestamp. Expiry needs no database write or scheduled job. ENTITY.STATE holds only states that require a write to change, so LOCKED does not belong there.

Counter increments should use atomic database updates. Forming a lock checks that both observed counters still match before writing, with bounded retries for conflicts. Resets use narrow writes. Generic profile updates must preserve this server-owned data, and must not change the administrative state.

Security Considerations

• Authorization and attribution. Lifecycle actions must require explicit permission. Actor identity and lock reasons must come from trusted server context, not caller-provided data.
• Account-state disclosure. Locked or disabled accounts should use normal authentication-failure responses, with restriction reasons hidden by default to reduce account enumeration.
• Lockout abuse. Count only actual failed verification attempts. Challenge requests, delivery failures, and provider errors must not increase lock counters. Independent rate limiting is still required.
• Recovery and challenges. Automatic locks may allow verified recovery, while administrative holds should block self-service recovery. Challenges must not be sent when the current state prevents their use.
• State integrity. Counters, locks, unlocks, and resets must use atomic or guarded updates. Normal profile updates must not overwrite or modify lifecycle runtime state.
• Consistent enforcement. Restrictions must be enforced across authentication, token issuance, sessions, recovery, and other applicable flows. Missing or invalid required state should fail closed.
• Distributed consistency. Multi-node deployments must prevent stale cached state from allowing access after an account is restricted.
• Containment and audit. Access restrictions must remain effective even if token revocation, session termination, or notification fails. Lifecycle actions and their outcomes should be securely audited without storing credentials, tokens, or unnecessary personal data.

Impacted Areas

• User Management
• Authentication

Alternatives Considered

A. How should an admin security hold be represented?

For a suspected compromise, an admin may need to stop access, replace unsafe credentials or recovery
channels, then invite the user to set a new credential before restoring access. The current DISABLED state already blocks access and allows admin edits. A dedicated admin-initiated credential-setup flow is future work under every option.

Factor	Option 1: LOCKED with a trigger	Option 2: add SUSPENDED	Option 3: replace DISABLED with SUSPENDED
Public statuses	ACTIVE, LOCKED, DISABLED	ACTIVE, LOCKED, SUSPENDED, DISABLED	ACTIVE, LOCKED, SUSPENDED
Admin security hold	LOCKED with ADMIN_INITIATED	SUSPENDED	SUSPENDED
Meaning of LOCKED	Automatic lock or admin hold	Automatic lock only	Automatic lock only
Distinguishing lock types in the API	Needs trigger detail or a separate status	Status is enough	Status is enough
Recovery rules	Must check the trigger	Separate rules per state	Separate rules per state
Self-service recovery	Automatic lock: allowed Admin-initiated lock: denied	LOCKED: allowed SUSPENDED: denied DISABLED: denied	LOCKED: allowed SUSPENDED: denied
Admin-initiated recovery	Admin-initiated lock: allowed DISABLED: denied	LOCKED: allowed SUSPENDED: allowed DISABLED: denied	LOCKED: allowed SUSPENDED: allowed
Admin actions	Lock/unlock and disable/enable	Suspend/unsuspend and disable/enable; unlock automatic locks	Suspend/unsuspend; unlock automatic locks
Admin Profile Update	LOCKED: Allowed DISABLED: only can enable	LOCKED / SUSPENDED: Allowed DISABLED: only can enable	LOCKED / SUSPEND: Allowed
Main cost	One status has two behaviours	Two similar admin restrictions to explain	No way to block admin profile update

Preference: option 3 if we do not need two distinct admin restrictions. Option 2 needs a clear reason to treat suspension and disablement differently, such as offering admin-initiated credential setup only while suspended.

B. Where should server-owned runtime data live?

Declarative entities loaded from resource files have no writable database row. Supporting runtime disable and
lock for them needs writable storage. The same question applies to future data such as verified attributes or last-login time.

Factor	Option 1: fallback extension table	Option 2: dedicated runtime-state table
Entities using the new table	Declarative entities and entities defined in future secondary user stores	Every entity
Existing ENTITY data	Stays where it is	Server-owned state moves to the new table
Choosing where to read and write	Depends on the entity source and field	One writable home for ThunderID-owned runtime value; source-owned values still require explicit resolution.
Profile updates	Must preserve server-owned fields stored in ENTITY	Profile writes cannot overwrite runtime state stored separately
Read cost	Extra lookup only where the extension is required	Join/additional lookup for database entities; secondary stores may require multiple reads if another extension is introduced
Status filtering	Entities in entity tableMust combine the source and fallback data	One runtime-state predicate; still needs source-aware listing
A declarative resource declaring its own system attributes	If the extension stores the whole SYSTEM_ATTRIBUTES document, runtime writes could replace system attributes declared by the resource. Ownership/merge rules are required so only extension-owned attributes are written there	Runtime-state storage is independent from declarative SYSTEM_ATTRIBUTES, so lock/disable updates cannot replace them
Future secondary user stores	Can split ownership: state supported by the user store can remain there, while ThunderID-only attributes/state can live in the extension	Runtime state remains in the dedicated table even if the secondary store can manage some state itself; this requires an explicit precedence model
Other ThunderID-owned attributes for secondary stores	The same extension can hold additional ThunderID-owned attributes that the external store cannot persist	A separate general extension may still be needed in addition to the runtime-state table
Number of data sources for secondary stores	Typically user store + extension	Could become user store + runtime-state store + general extension if ThunderID later needs to persist other system attributes/ attributes locally

Preference: Option 2, dedicated runtime-state table

Keep ThunderID-owned runtime state in one writable location for every entity, regardless of whether its profile comes from database, resource file, or secondary user store. This gives failure counting, locking, credential-change tracking, and future verification data one storage implementation. Separating ownership also prevents profile updates from overwriting runtime state.

Suggested structure in entitydb:

CREATE TABLE "ENTITY_RUNTIME_STATE" (
    DEPLOYMENT_ID       VARCHAR(255) NOT NULL,
    ENTITY_ID           VARCHAR(36)  NOT NULL,
    STATE               VARCHAR(50),
    SYSTEM_ATTRIBUTES   JSONB NOT NULL DEFAULT '{}'::jsonb,
    CREATED_AT          TIMESTAMPTZ NOT NULL,
    UPDATED_AT          TIMESTAMPTZ NOT NULL,

    PRIMARY KEY (DEPLOYMENT_ID, ENTITY_ID),
    CHECK (jsonb_typeof(SYSTEM_ATTRIBUTES) = 'object')
);

ENTITY_RUNTIME_STATE table name is not finalized.

Tradeoff: additional read integration now, and potentially another extension later. Prefer this over permanently routing ThunderID-owned runtime writes between ENTITY and fallback storage. Existing runtime data must be preserved before switching authority.

[yeshandev]

lastSignInAt tracking

The same storage approach selected for account-lock runtime attributes can also support tracking lastSignInAt. This is another server-observed runtime value, produced from successful authentication activity rather than profile updates.

lastSignInAt can be persisted alongside the lock-related runtime attributes using whichever storage approach is selected for them. It should be updated when access is successfully granted and exposed as a read-only attribute through the Users API. External systems can then use the value to identify inactive accounts and apply their own dormancy or lifecycle policies.

Since tracking this value introduces writes on successful sign-ins, the implementation can also consider configurable tracking and a resolution window to reduce unnecessary writes for frequently accessed accounts.

account_access:
  user:
    record_last_sign_in_at: false
...

[yeshandev]

Finalized account states

ACTIVE, LOCKED, BLOCKED, DISABLED

These are the published statuses. They are not four values of one column: DISABLED must preserve a
LOCKED or BLOCKED condition underneath it, so the four names are a precedence projection over three
independent dimensions.

Published	Dimension	Stored in	Scope	Clears itself
LOCKED	automatic protection	accessState.lock	verifier by default, entity by policy or after an unblock	yes
BLOCKED	administrative containment	accessState.block	entity	no
DISABLED	administrative enablement	ENTITY.STATE	entity	no

Precedence on the wire: DISABLED > BLOCKED > LOCKED > ACTIVE, derived at read time.

Only DISABLED is a value in ENTITY.STATE. Keeping BLOCKED out of that column is what makes
disable preserve a block by layout rather than by logic — enable writes a column that never held
the block.

Transitions

stateDiagram-v2
    direction LR

    [*] --> ENABLED

    state ENABLED {
        direction LR
        [*] --> ACTIVE

        ACTIVE  --> LOCKED  : failed attempts reach threshold
        LOCKED  --> ACTIVE  : expiry / self-service recovery / admin unlock

        ACTIVE  --> BLOCKED : admin block<br/>revoke sessions + tokens
        LOCKED  --> BLOCKED : admin block<br/>revoke sessions + tokens

        BLOCKED --> LOCKED  : admin unblock<br/>entity-scoped lock, no expiry
    }

    ENABLED  --> DISABLED : admin disable · revoke · condition preserved
    DISABLED --> ENABLED  : admin enable · preserved condition restored

Loading

Unblock is not a release. It clears containment and leaves the account LOCKED, entity-wide and
without a timer, because releasing containment asserts this identity is not compromised, not this
identity is ready to be used. The account still has to prove control — through self-service recovery,
or through an operator who unlocks deliberately.

What each status permits

	ACTIVE	LOCKED (automatic)	LOCKED (post-unblock)	BLOCKED	DISABLED
Fresh sign-in	allow	deny the held verifier	deny all	deny	deny
Existing sessions and tokens	keep	keep¹	already revoked	revoke	revoke
Self-service recovery	allow	allow, and it clears the lock	allow, and it clears the hold	deny	deny
Admin profile updates	allow	allow	allow	allow	deny
Failures counted	yes	yes	no	no	no
Expires on its own	—	yes	no	no	no
Cleared by	—	expiry · recovery · unlock	recovery · unlock	unblock	enable
Credentials and assignments	kept	kept	kept	kept	kept

BLOCKED keeps the record writable and DISABLED does not, which makes BLOCKED the remediation
window.

Storage pattern

{
  "accessState": {
    "lock": {
      "verifiers": {
        "credential": { "failureCount": 0, "lastFailedAt": "2026-09-02T10:04:12Z",
                        "lockCount": 2,    "unlockAt":     "2026-09-02T10:19:12Z" },
        "otp":        { "failureCount": 1, "lastFailedAt": "2026-09-02T10:03:50Z",
                        "lockCount": 2,    "unlockAt":     "2026-09-02T10:19:12Z" }
      }
    },
    "block": { "since": "2026-09-10T11:02:00Z" },
    "lastLoginAt": "2026-09-09T18:22:04Z"
  }
}

Under lock_granularity: entity, every countable failure folds into one entry:

"lock": {
  "entity": { "failureCount": 0, "lastFailedAt": "2026-09-02T10:04:12Z",
              "lockCount": 2,    "unlockAt":     "2026-09-02T10:19:12Z" }
}

lock carries one of two shapes, never both

lock.entity present and live        →  every verifier is held
else lock.verifiers.<scope> live    →  that scope is held
else                                →  nothing is held

The post-unblock hold

Unblock removes block and replaces lock wholesale, in one write, since both are members of the same
document:

"accessState": {
  "lock": { "entity": { "unlockAt": "9999-12-31T23:59:59Z", "reason": "POST_UNBLOCK" } },
  "lastLoginAt": "2026-09-09T18:22:04Z"
}

[PasinduYeshan]

Updated decision

After further discussion with Jerad, we agreed on the following changes:

• Rename BLOCKED to SUSPENDED.
• Remove DISABLED for this phase.
• The finalized published states are therefore:

ACTIVE
LOCKED
SUSPENDED

The main behavioral difference between the previously proposed SUSPENDED/BLOCKED state and DISABLED was that DISABLED also prevented administrators from updating the profile. We do not currently have a strong enough requirement for that additional restriction to justify introducing another lifecycle state.

Suspended state

Suspension will also carry metadata such as when the suspension happened and the reason:

{
  "accessState": {
    "suspend": {
      "suspendedAt": "2026-09-15T10:30:00Z",
      "reason": "SECURITY_CONCERN"
    }
  }
}

SUSPENDED will be reflected in STATE as well, allowing the current entity state to be checked directly, while accessState.suspend retains the suspension-specific metadata.

This also keeps the model extensible. If we introduce a DISABLED-like state later, transitioning to DISABLED does not need to discard the underlying lock or suspension information. The existing accessState.lock and accessState.suspend records can remain intact and become effective again when the entity is re-enabled.

[PasinduYeshan]

Finalized storage and user response

Storage

For database-backed entities, lifecycle state and runtime attributes remain in the existing ENTITY table:

• Lifecycle state: ENTITY.STATE
• Runtime attributes: ENTITY.SYSTEM_ATTRIBUTES.accessState

For declarative entities, the resource file is treated as the source of the entity definition, but it cannot store runtime changes. Therefore, server-owned runtime state is stored in ENTITY_EXTENSION.

ENTITY_EXTENSION acts only as writable fallback storage for values that cannot be persisted back to the original entity source. This includes lifecycle state changes and registered server-owned attributes such as accessState.

For declarative entities, a configured state: is treated as the initial state. Once a runtime state is written to ENTITY_EXTENSION, that runtime value becomes authoritative.

Runtime-only values such as failure counters, unlockAt, and lockCount should not be accepted from declarative resource files.

---

User API response

The effective status is derived at read time using the following precedence:

DISABLED > BLOCKED > LOCKED > ACTIVE

Proposed response:

{
  "id": "01a0942a-9793-712b-bdd9-1b0faa69af2e",
  "type": "Person",
  "attributes": {
    "email": "user1@gmail.com",
    "username": "user1"
  },
  "status": {
    "value": "LOCKED",
    "details": {
      "reason": "FAILED_ATTEMPTS",
      "lockedScopes": [
        {
          "scope": "credential",
          "expiresAt": "2026-09-12T10:45:15Z"
        },
        {
          "scope": "otp",
          "expiresAt": "2026-09-12T10:50:15Z"
        }
      ]
    }
  },
  "lastLoginAt": "2026-09-11T08:24:12Z"
}

details is omitted when there is nothing additional to report.

lockedScopes is a list because multiple verifier-specific locks can exist at the same time. Entity-wide locking is represented using:

{
  "scope": "entity"
}

An omitted expiresAt means the lock does not expire automatically.

Status precedence also applies to the returned details. For example, if an entity is both blocked and locked, the response exposes BLOCKED and its details rather than the underlying lock.

These details should only be exposed through authorized management APIs. Authentication error responses should not reveal lock scope, reason, or expiry information.

Agents and applications

Agents and applications use the same status structure.

Currently, only the following effective statuses apply:

ACTIVE
BLOCKED
DISABLED

Automatic locking is not enabled for Agents and applications entity categories.

[PasinduYeshan]

Finalized decision: dedicated entity runtime data

After the discussion, the finalized direction is to introduce a dedicated table for ThunderID-owned runtime data rather than storing it in ENTITY for database-backed entities and using fallback storage only for declarative entities.

The proposed name is ENTITY_RUNTIME_DATA:

CREATE TABLE "ENTITY_RUNTIME_DATA" (
    DEPLOYMENT_ID       VARCHAR(255) NOT NULL,
    ENTITY_ID           VARCHAR(36)  NOT NULL,
    STATE               VARCHAR(50)  NOT NULL,
    RUNTIME_ATTRIBUTES  JSONB        NOT NULL DEFAULT '{}'::jsonb,
    CREATED_AT          TIMESTAMPTZ  NOT NULL DEFAULT NOW(),
    UPDATED_AT          TIMESTAMPTZ  NOT NULL DEFAULT NOW(),

    PRIMARY KEY (DEPLOYMENT_ID, ENTITY_ID),

    CHECK (jsonb_typeof(RUNTIME_ATTRIBUTES) = 'object')
);

The table name and exact columns are still open for discussion.

ENTITY_RUNTIME_DATA is preferred over ENTITY_RUNTIME_STATE since this storage will contain more than lifecycle state. It can also hold ThunderID-owned runtime information such as accessState, lastLoginAt and other runtime values introduced later.

One additional reason for separating this data is migration support. We need to support a sign-in-only mode where the existing ENTITY table remains read-only, while authentication must still be able to update runtime information such as failed-attempt counters, locks, and last-login information. A dedicated runtime table keeps these writes independent from the entity source.

This also gives the same runtime persistence model for database-backed, declarative, and future secondary-store entities instead of routing writes differently based on the entity source.

CREATED_AT and UPDATED_AT here represent the lifecycle of the runtime-data row itself, not the entity's creation or profile-modification timestamps.

[PasinduYeshan]

Automatic lock notification

For admin operations such as Disable / Enable and Block / Unblock, the operation is executed through a flow, so any required notification can be configured as part of that flow.

Automatic locking is different because a lock can be formed during credential verification across different authentication flows. Therefore, the automatic-lock notification should be configured together with the common account-lock configuration.

Proposed configuration:

account_access:
  user:
    lock_granularity: verifier       # verifier or entity

    default:
      enabled: true
      threshold: 5
      failure_window_seconds: 900
      lock_durations_seconds: [300, 900, 3600, 86400]
      lock_decay_seconds: 86400
      disclose_hold_reason: never

    scopes:
      otp:
        threshold: 3
        failure_window_seconds: 600
        lock_durations_seconds: [300, 900]
        lock_decay_seconds: 3600

      entity:

    notifications:
      on_lock:
        email:
          enabled: true
          recipient_attribute: email
          user_types:
            employee:
              recipient_attribute: workEmail
            customer:
              recipient_attribute: emailAddress
            service_user:
              enabled: false

Proposed behavior:

• email.enabled controls automatic-lock email notifications and should default to false.
• recipient_attribute defaults to email.
• User-type-specific overrides can select a different recipient attribute or disable the notification for that type.
• If the configured recipient attribute is missing or invalid, skip the notification without affecting the lock.
• An email should only be scheduled when a new automatic lock is successfully formed and committed. Repeated failed attempts while the lock is already active should not generate additional notifications.

[thiva-k]

Hi @yeshandev @PasinduYeshan ,

The authn provider manager's just routing between authn provider implementations, it shouldn't own this governance logic IMO. And if we push governance to the manager level, it'll need an entity/governance dependency even for setups that only use an external custom provider and manage their own governance. That dependency would just sit there unused since the manager can't check state for entities it doesn't own anyway.

For entities we manage, we handle governance too. If someone's entities live on their side, they implement that as part of their own authentication logic, not something we can enforce from the manager.

[PasinduYeshan]

Agreed. This was one of the concerns I had with handling governance at the manager level. Keeping the manager focused on routing, while each authentication provider handles governance for the entities it owns, seems like the cleaner approach.

[indeewari]

Hi @PasinduYeshan ,

Informative proposal.

1. BLOCKED status
   I noted the new concept of BLOCKED status which will be useful in account management required while transactions as are rejected from that account. In this case what will be the notification story(end user and the downstream systems) ?

End user notifications - As all the modifications are done by the admin which may or may not notify to the account holder or end user case by case.
Down streams - Still down streams are interested on all the profile level modifications

2. LOCKED status
   Also regarding the agents, when agent as a subject(behaves as a user), I believe the LOCKED status is valid use case. When agent as an application, yes, your list of status will cover.

Thanks and Regards

[PasinduYeshan]

1. IMO, we should not decide whether profile update notifications/events are sent based on the current lifecycle state.

If profile updates are allowed while the account is BLOCKED, those updates should continue to be propagated to downstream systems through the normal profile-change/eventing mechanism. BLOCKED should control what the account is allowed to do, but should not implicitly suppress profile-level change notifications.

For end-user notifications related specifically to the Block/Unblock operation, that can be configured as part of the corresponding admin flow.

2. Yes, agreed. When an agent acts as a subject/user, automatic locking is a valid use case. We will provide this capability in a configurable way so deployments can enable or disable automatic locking for agents depending on how agents are used.

[PasinduYeshan]

Spec PR

• Add account lock and suspension specification #5442

[PasinduYeshan]

UIs

Config UI

[PasinduYeshan]

cc: @jeradrutnam @brionmario