kanidm: an unset authsession_expiry means sessions never expire, not one day #308

Nytt ärende

Stängd

öppnade 2026-08-01 14:30:09 +00:00 av supernaut · 0 kommentarer

supernaut kommenterad

2026-08-01 14:30:09 +00:00

Ägare

Found while declaring the account policy for #275, which deliberately recorded this as a recommendation
rather than applying it — changing session lifetime is its own reviewed change.

The finding

authsession_expiry is not set on idm_all_persons. The natural reading is that it therefore falls
back to a sensible default of one day. It does not.

Two constants exist in Kanidm 1.10.4, server/lib/src/constants/mod.rs:174-176, and their own comments
say what they are:

// Maximum - Sessions have no upper bound.
pub const MAXIMUM_AUTH_SESSION_EXPIRY: u32 = u32::MAX;
// Default - sessions last for 1 day
pub const DEFAULT_AUTH_SESSION_EXPIRY: u32 = 86400;

The DEFAULT_ constant appears only in the server's own tests, not on the resolution path — so an unset
policy resolves to the maximum, i.e. u32::MAX seconds. Authentication sessions on production
therefore effectively never expire.

A second trap in the same area: reset-auth-expiry is an HTTP DELETE
(libs/client/src/group.rs:40-46). It purges the attribute rather than restoring a default, so
"resetting" it is what produces the never-expires state, not what fixes it.

Why it matters

Principle 4 is least privilege and being careful with users' data. A session that never expires means a
stolen or abandoned session cookie stays valid indefinitely — on a shared machine, a lost laptop, or
after an employment change. This is the single identity-posture knob most likely to be assumed rather
than checked, precisely because "unset" reads as "default".

It is also invisible: nothing in this repository diffs when an upstream default changes, which is the
general gap #275 set out to close.

Recommendation

kanidm group account-policy auth-expiry idm_all_persons 86400 --name idm_admin

and update declared: 86400 for authsession_expiry in kanidm_account_policy
(roles/kanidm/defaults/main.yml) in the same change, or the next apply fails the new
account-policy gate. That failure would be the gate working correctly.

Reversible, and existing sessions keep the expiry they were granted, so nobody is signed out by the
change itself.

Pick the value deliberately rather than adopting 86400 because it appears above — that number is
Kanidm's own test-only default, not a considered choice for this service. privilege_expiry is worth
deciding in the same pass.

Verify before acting

The live value was not read: the cached idm_admin CLI session had expired and there is no
read-only route to it. Confirm with kanidm group get idm_all_persons before changing anything — if
authsession_expiry turns out to be set after all, the premise above is wrong and only the
documentation needs correcting.

Found while declaring the account policy for #275, which deliberately recorded this as a recommendation rather than applying it — changing session lifetime is its own reviewed change. ## The finding `authsession_expiry` is not set on `idm_all_persons`. The natural reading is that it therefore falls back to a sensible default of one day. It does not. Two constants exist in Kanidm 1.10.4, `server/lib/src/constants/mod.rs:174-176`, and their own comments say what they are: ```rust // Maximum - Sessions have no upper bound. pub const MAXIMUM_AUTH_SESSION_EXPIRY: u32 = u32::MAX; // Default - sessions last for 1 day pub const DEFAULT_AUTH_SESSION_EXPIRY: u32 = 86400; ``` The `DEFAULT_` constant appears only in the server's own tests, not on the resolution path — so an unset policy resolves to the **maximum**, i.e. `u32::MAX` seconds. **Authentication sessions on production therefore effectively never expire.** A second trap in the same area: `reset-auth-expiry` is an HTTP `DELETE` (`libs/client/src/group.rs:40-46`). It **purges** the attribute rather than restoring a default, so "resetting" it is what produces the never-expires state, not what fixes it. ## Why it matters Principle 4 is least privilege and being careful with users' data. A session that never expires means a stolen or abandoned session cookie stays valid indefinitely — on a shared machine, a lost laptop, or after an employment change. This is the single identity-posture knob most likely to be assumed rather than checked, precisely because "unset" reads as "default". It is also invisible: nothing in this repository diffs when an upstream default changes, which is the general gap #275 set out to close. ## Recommendation ``` kanidm group account-policy auth-expiry idm_all_persons 86400 --name idm_admin ``` and update `declared: 86400` for `authsession_expiry` in `kanidm_account_policy` (`roles/kanidm/defaults/main.yml`) **in the same change**, or the next apply fails the new account-policy gate. That failure would be the gate working correctly. Reversible, and existing sessions keep the expiry they were granted, so nobody is signed out by the change itself. Pick the value deliberately rather than adopting 86400 because it appears above — that number is Kanidm's own test-only default, not a considered choice for this service. `privilege_expiry` is worth deciding in the same pass. ## Verify before acting The live value was **not** read: the cached `idm_admin` CLI session had expired and there is no read-only route to it. Confirm with `kanidm group get idm_all_persons` before changing anything — if `authsession_expiry` turns out to be set after all, the premise above is wrong and only the documentation needs correcting.

supernaut lade till etiketterna

area/identity

area/security

ready-for-implementation

type

task

2026-08-01 14:30:25 +00:00

supernaut lade till detta till projektet Bitborg Infrastructure

2026-08-01 14:30:26 +00:00

supernaut refererade till detta ärende från en incheckning

2026-08-02 15:50:52 +00:00

fix(kanidm): bound person auth sessions to 24 h instead of never expiring