Specify the access outcome, not just an SSO checkbox
A requirement that an authentication platform support SAML single sign-on is incomplete unless it explains who should enter which tenant, with what permissions, and what happens when their role or employment changes. Successful authentication establishes an identity assertion under an agreed federation relationship. It does not automatically authorize every domain, customer, report or administrative action in the application. Procurement and implementation reviews should therefore test the access outcome rather than accepting a successful login as the entire requirement.
This article is a proposed requirements framework. It does not claim that EmailAuth implements SAML, just-in-time provisioning, particular roles or any session-control feature. No identity provider was configured, assertion submitted or access granted. Microsoft's SAML protocol documentation provides a concrete official description of an Entra-supported exchange, while the proposed acceptance criteria still require confirmation against the actual platform and identity provider.
Bind the federation to the intended application and tenant
Document the identity provider, service provider, intended tenant, approved federation administrator and configuration owner. Record the application identifier and assertion-consumer endpoint from approved configuration evidence, without copying credentials or complete sensitive assertions into a general worksheet. The Entra documentation describes issuer, audience, response correlation and subject-confirmation elements. These are not interchangeable labels: an assertion intended for one application should not become authority for a different application merely because it has a valid signature.
Require the actual implementation to validate the protocol elements appropriate to its supported flow, including trust in the issuer and signing material, intended audience and recipient, validity conditions and request correlation where applicable. Do not invent a single validation recipe covering every initiated flow or library. Ask the supplier to document its supported flows and security checks, then verify them in an authorized isolated environment. A sample XML response in documentation is not evidence that the target platform enforces those checks.
Keep authentication and authorization separate
Azure's multitenant identity guidance distinguishes role-based and resource-based authorization and warns against federation misconfigurations granting access to unintended tenants. Use that distinction when writing requirements. A user authenticated by a customer's identity provider still needs an authorized relationship to the correct application tenant and resources. An email-address suffix alone should not be treated as a complete tenancy or role decision without a documented approved mapping.
Specify the permitted roles and resource scope independently of the login method. A report viewer may read selected domains but not export all customers; a tenant administrator may manage members without changing another tenant's settings. Define who may establish or change those mappings and how changes are reviewed. If group or role attributes are used, document their source, accepted values and behavior when attributes are absent or unexpected. These are proposed controls, not claims about a particular product's role model.
Define join and role-change behavior
For a new user, state whether the account must be provisioned in advance or whether supported just-in-time behavior is allowed. Document how the intended tenant is selected and whether approval is required before the first session can access data. Do not infer automatic provisioning from the availability of SAML authentication. The supplier must identify its actual supported lifecycle behavior and any differences between administrative, interactive and API access.
For role changes, specify when new permissions should take effect and how existing sessions are handled. A requirement should distinguish removal of a role from disabling an account. It should also state whether cached authorization decisions are refreshed and how the observed outcome will be checked. Avoid assuming that a new assertion on the next login updates every already active session. Retain actual evidence of both permitted and denied actions after a change when the authorized test is eventually performed.
Make disablement and session handling explicit
An employee's identity-provider account may be disabled while a service-provider session remains active according to the application's own behavior. The requirements must ask how existing sessions, remembered devices, local fallback accounts and noninteractive credentials are treated. SSO availability does not itself establish a universal logout or revocation guarantee. Require the supplier to describe supported revocation mechanisms, expected limitations and the evidence needed to verify them.
Separate routine offboarding from emergency containment. Routine changes may follow scheduled lifecycle synchronization; an incident may require an authorized administrator to revoke access promptly through a different supported path. This article does not perform or approve those security changes. It proposes that their ownership and verification criteria be documented before adoption, rather than discovered during an incident when the team assumes disabling the identity-provider account was sufficient.
An SSO acceptance worksheet
Create a worksheet with identity-provider configuration reference, service-provider tenant, user test identity, intended role, resource scope, supported flow and expected result. Add rows for joining, role increase, role reduction, disablement, active-session behavior and any approved local recovery path. Record who authorizes each test and which environment contains the fixtures. Do not include real passwords, session cookies, private signing keys or complete production assertions in the worksheet.
Include negative cases that demonstrate boundaries: an identity intended for another tenant must not gain access, a viewer must not receive administrative privileges, and a removed role must not silently remain effective beyond the documented behavior. Phrase these as acceptance criteria until actual results exist. A failed test should record the action and observed response without assuming the failure was securely enforced merely because the interface hid a button. Server-side authorization needs its own evidence.
Fictional diagnosis: login succeeds but scope is wrong
A fictional organization evaluates a platform for two customer teams. Both use the same corporate identity provider, but their application tenants must remain separate. An initial demonstration shows successful SSO and a report dashboard. The reviewer notices that the demonstration never established which tenant the test user was bound to or whether an existing session would retain a role after removal.
The proposed follow-up is an authorized fixture-based test that checks tenant binding, role reduction and disablement separately. A successful login would count only for the authentication part of the requirement. No such test was executed here, and the fictional platform is not an allegation about EmailAuth or another named service. The example explains why an apparently complete SSO demonstration can leave material access questions unanswered.
Require evidence before accepting the capability
A useful supplier response identifies supported protocol flows, lifecycle integrations, role mapping, session behavior, fallback access and audit evidence. It also states limitations plainly. Do not convert a roadmap statement or a screenshot into proof of implementation. Preserve the product version and configuration context so the acceptance result remains interpretable after a provider change.
The catalogue requires testing join, role change, disablement and active-session handling with current platform support. That original evidence remains open. This draft provides proposed requirements and a fictional exercise, not test results. Human specialist review, source applicability, production routes, accessibility and owner release are also open. Publication and any capability claim require authorized observations of the actual platform rather than inference from SAML documentation alone.