Administrators will sometimes configure oauth2 clients with `idm_all_accounts`
as an allowed scope group. Despite anonymous being *unable* to interact with
oauth2, this still allowed oauth2 clients to be read by anonymous in this
configuration. For some users, this may be considered a public info
disclosure.
During other testing I noticed that passkeys no longer worked
on a reauthentication. This was due to a regression in you
guessed it, cookies, where the auth session id wasn't being
removed properly.
* make everything cookie consistent
* Stricter on expiry
* Relearn a painful lesson about needing domains in removal cookies
* fix: DRY cookie creation code and reduce the sins
This adds further testing of SCIM sync, especially around
conversion of the SCIM Sync Person and Group types into
SCIM Entry. This test would have prevented #3298 and
#3299 from occuring.
During testing two more fixes were found. external_id should have
been required (not optional) and a group with no members would
cause a serialisation issue.
Add an on-load handler to pkhtml.js so that when the partial
view is displayed passkey auth is automatically prompted for.
If the users browser blocks this event, the fallback manual
buttons still exist.
This was a commonly requested re-addition to the new webui. This
adds the ability for someone to scan a qr code or follow a link
to enrol another device to their account.
OAuth2 session resumption was accidentally made a permanent cookie
which led to continuing issues with it causing invalid redirections
after login. Make this a session only cookie.
Rather than the generic 'invalid state' error, we now return
proper site-specific errors for credential commit failures, with
error messages to explain what went wrong.
During a re-auth flow, the password was not autocompleted once
totp was autocompleted. This is because in a normal login flow
the autocomplete is performed on the first login.html page,
but in a re-auth we skip that page.
This adds the proper handling to allow the pw to autofill
in the background once the TOTP is completed.
If an OAuth2 auth request resume cookie was present, and at the same
time the kani instance was restarted, the cookie would now fail
to validate on the instance. This caused the user to experience an auth
loop where after every authentication they would see an error *despite*
logging in correctly, and then a refresh would show the correct
apps page.
This removes the auth_req cookie correctly even if it fails to
deserialise.
Post release some small user issues arose
* Optimise the autofocus for logins with passkeys to limit clicks
* Sort login mechs by strength
* Fix cookies to persist between browser restarts
* Re-migrate all acps to force updating
* Update server/lib/src/server/migrations.rs
---------
Co-authored-by: James Hodgkinson <james@terminaloutcomes.com>
A fault existed in the server's internal migration code, where attributes
that were multivalued would be merged rather than replaced in certain
contexts. This migration path is used for access controls, meaning that
on upgrades, attributes that were meant to be removed from access
controls or changes to access control target groups were not reflected
during the upgrade process.
This has a potentially low security impact as it may have allowed
users to change their name/displayname even if the administrator
had disable the name_self_write access control.
- Resolve an issue where oauth2 could trigger the login page to
incorrectly redirect to an oauth2 application instead of apps
- Add indication of what client application we are accessing
if the session is not yet authenticated
