Harden UserProvisioner: retry, inactivity guard, unverified adoption

[Fivell]

Three security fixes for UserProvisioner, surfaced by code review. Each one has a failing spec first, then the fix.

1. on_login fires twice on a race

When two first sign-ins for the same (provider, uid) happen at the same time (two browser tabs, two workers), the loser hits RecordNotUnique and the provisioner retries. The old retry path re-ran on_login on the now-found row. If the host hook writes to an audit log, sends a webhook, or queues a welcome email — that all happens twice.

The @retried flag set by save!'s rescue is now read in #call to short-circuit right after the row is found:

admin_user = find_or_adopt_or_build
return admin_user if @retried

The hook ran once on the (discarded) in-memory build during the first attempt — that's enough.

2. Disabled users were written to the DB before being rejected

If the host's on_login flips enabled = false and returns truthy:

c.on_login = ->(user, _claims) do
  user.enabled = false if blocked?(user)
  true
end

The provisioner used to save the row anyway. The controller would then reject the sign-in via active_for_authentication? — but the row was already written. Repeated attempts grew the table.

Moved the check inside the provisioner, between the hook and save!:

unless admin_user.active_for_authentication?
  raise ProvisioningError, admin_user.inactive_message.to_s
end
save!(admin_user)

3. Account adoption via unverified email

A legacy admin row (ceo@example.com, provider: nil, uid: nil — seeded by DBA before SSO) could be claimed by anyone the IdP said owned that email. If the IdP doesn't verify email ownership (guest tenants, lax Keycloak realms, Zitadel without a verification policy), the attacker registers ceo@example.com there and walks off with the account.

Now refuses adoption when the IdP explicitly marks the email as unverified:

if @claims["email_verified"] == false
  raise ProvisioningError, "Identity not verified by the IdP — refusing adoption"
end

Note the == false — many IdPs never emit email_verified at all (Zitadel, plain Keycloak). A strict != true would break them. So: block only when the IdP says "do not trust this", trust the host's IdP choice otherwise. If you want a strict opt-in mode, a config.require_verified_email_for_adoption flag is a natural follow-up.

Commits

• Failing specs (5 examples, all RED)
• Fixes (all GREEN, full suite stays green)

Test plan

• bundle exec rspec — 103/0
• bundle exec rake spec:engine — 7/0
• bundle exec rake spec:isolated — 5/0
• CI matrix (Ruby 3.2/3.3/3.4 × ActiveAdmin 3.5/4.0) — all green