v1.4.0

Added

• Sign in with your identity provider. IdPVault now supports OpenID Connect
  single sign-on (authorization code with PKCE), configured in Administration >
  System settings > Single sign-on. Point it at your provider's issuer URL and
  it reads the rest from the discovery document; a Test connection button
  checks the provider before you turn anything on. Available on Business and
  MSP licenses.
• SCIM 2.0 provisioning. Your identity provider can create, update and
  deactivate IdPVault accounts automatically. Deactivating someone in your
  directory disables their IdPVault account - it is never deleted, so the
  audit trail survives.
• Push Groups. Groups your provider pushes over SCIM appear in their own
  section, and each can be mapped to a role. A person gets the highest role
  they are mapped to across their groups, re-evaluated whenever their
  membership changes. Leaving every mapped group returns them to the default
  role for SSO users.
• People can now sign in with their email address. Names (first and last) were
  added to accounts and are shown as "First Last (email)" throughout.
• SAML 2.0 single sign-on, alongside OpenID Connect. Pick the protocol in
  System settings and the fields change to match. Paste your provider's
  metadata URL and IdPVault reads the entity ID, sign-in endpoint and signing
  certificate from it; save again after a certificate rotation to pick up the
  new one. Your metadata URL is shown for import at the provider.
• SSO mode Required turns password sign-in off, and break-glass accounts.
  Flag an administrator as break-glass and that account keeps password
  sign-in when SSO is required - the way back in if your identity provider is
  down. Break-glass sign-ins are called out separately in the audit log.
• Client users can be flagged external. External people are not in your
  directory, so they keep password sign-in when SSO is required. Org-scoped
  roles are external automatically.
• System settings sections are collapsible, each with a status chip showing
  what is configured without opening it.
• App users can now be edited. Edit on any row opens first and last name,
  email, role, client org, and the external and break-glass flags. The table
  gained a Name column showing "First Last (email)" and an MFA column, and
  Reset MFA only appears on accounts that actually have it on.
• Your own row is editable - on a single-admin install that is the only way to
  flag the first break-glass account. Changing your own role or client org, or
  disabling yourself, still needs another administrator.

Changed

• Accounts created before this release keep signing in with their username
  exactly as before. Nothing needs to be changed on an existing install.
• Your identity provider owns the names of anyone who signs in through it -
  they refresh at every sign-in.

Security

• New accounts created by a provider are never placed inside an MSP client
  organization, and group role mapping only ever grants the global
  administrator or user roles. Client organization roles stay assigned inside
  IdPVault.
• Role mapping will not demote the last active administrator and never changes
  a break-glass account, and provisioning will not deactivate the last active
  administrator. Every skipped change is recorded in the audit log with its
  reason.
• SSO cannot be set to Required until at least one active administrator is
  flagged break-glass and has MFA enabled. Once required, that pairing cannot
  be taken away: disabling, deleting, demoting, clearing break-glass on, or
  resetting MFA for the last such account is refused, and your directory
  cannot deactivate it over SCIM either.
• The last active administrator can no longer be disabled, deleted or demoted
  by any route.
• Accounts created by your identity provider cannot sign in with a password at
  all, in any mode.
• Deleting a user is now two deliberate steps: disable first, then delete. The
  Delete button only appears on an account that is already disabled.
• Email addresses are unique across accounts, compared case-insensitively.
• Deleting a user now also removes their trusted-device records, which
  previously could refuse the delete outright.