Feature proposal: Microsoft Entra SSO for the agent/technician portal

[thvevirtue]

Problem

The client portal already supports Microsoft Entra ID (Azure AD) SSO login (client/login_microsoft.php), but technicians/agents have no SSO option at all - only local username/password.

Proposed approach

• A separate Entra App Registration for agent SSO (config_azure_agent_client_id / config_azure_agent_client_secret), distinct from the existing client portal app, so staff and client sign-in can be scoped/consented independently.
• Settings > Identity Providers gains an "Agent/Technician Portal SSO" section to configure it, showing the redirect URI to register in Entra.
• New agent/login_microsoft.php mirrors the client portal's existing OAuth2 authorization code flow, but matches the signed-in Microsoft account against the users table directly (user_type = 1, i.e. agents) and never joins against contacts/clients - so it cannot match a client portal account regardless of email overlap.
• Technician accounts get an Auth Method selector (Local / Microsoft Entra) on the user edit modal, matching the existing pattern already used for client contacts.
• A "Sign in as Agent with Microsoft Entra" button appears on the unified login page once an agent app registration is configured (hidden otherwise).
• A DB migration adds the two new settings columns, following the existing per-version admin/database_updates/ convention.

This is incremental (no new runtime dependencies, no framework changes) and mirrors an existing, working pattern in the codebase rather than introducing a new one.

Status

Implemented and tested against a live install (fresh php -l sweep, end-to-end OAuth redirect test with a dummy App Registration, verified non-agent Entra accounts are cleanly rejected). Branch is ready on my fork: thvevirtue/itflow@master...thvevirtue:itflow:feature/agent-entra-sso

I understand PRs from the community are currently paused - opening this as an issue first per CONTRIBUTING.md's guidance to discuss approach before submitting anything larger than a bug fix. Happy to open a PR once the approach is agreed and/or PRs reopen.

[wrongecho]

Hello. Please raise on the forum.

[thvevirtue]

Update: addressed the E2EE credential vault gap raised by @wrongecho and @bigbug above.

Root cause confirmed: the credentials module wraps a site-wide master key separately per user (users.user_specific_encryption_ciphertext), keyed from the user's local password via PBKDF2 (functions/security.php). Login normally calls decryptUserSpecificKey() + generateUserSessionKey() to unlock it, but that never runs for SSO logins (no password is ever available), so SSO-only agents could log in fine but couldn't view or add credentials.

Added a self-service Unlock Vault flow, decoupled from login, that reuses the existing crypto primitives unmodified:

• New POST handler that verifies the vault passphrase and populates the session/cookie exactly like a local login would.
• A modal + persistent nav icon prompting for the vault passphrase whenever it's locked (worded to make clear this is not the SSO/login credential).
• Existing local users who switch to SSO can keep unlocking with their old password. Pure SSO-only users can have an initial vault passphrase bootstrapped by an admin via the existing Reset Password flow.

Branch (built on top of the agent Entra SSO branch, same fork): thvevirtue/itflow@master...thvevirtue:itflow:feature/agent-vault-unlock

Happy to open this as a PR too if/when community PRs reopen, or fold it into a broader SSO PR - whichever the team prefers.