Where Are You From? is a federation service that asks a user to choose their home organisation so the login can be routed to the correct identity provider. It supports organisation discovery during single sign-on. Defenders should validate selection lists, prevent phishing-style lookalike discovery pages, and log routing failures and misuse.
How federation discovery works in practice
Where Are You From? is a home-organisation discovery step in the sign-in flow. Instead of sending everyone to one universal login screen, the service asks the user which organisation they belong to, then routes the session to the matching identity provider. The core job is to reduce ambiguity in multi-organisation federation while keeping the user on the correct authentication path.
The mechanism is usually simple: present a branded selection screen, accept an organisation choice, then hand the browser to the right federation endpoint or identity provider. That makes the discovery page part of the trust boundary, not just a convenience screen. If the user is routed to the wrong provider, the login may fail, or worse, succeed against the wrong tenant or trust relationship.
Because the page sits early in the authentication journey, the design needs to protect both usability and trust. The selection list should be curated, validated, and resistant to spoofing, especially where attackers might imitate a legitimate discovery page to capture credentials or steer a user into an unsafe login path. Discovery should help the user find the correct identity provider, not create a new place where trust can be abused.
Why organisation discovery is a security-sensitive control
The main security issue is that organisation discovery can be manipulated if the selection experience is too open or too easy to imitate. A lookalike page can harvest information about which organisation a user belongs to, then redirect them into a phishing flow that resembles normal single sign-on. That is why the discovery step should be treated as an authenticated security control surface, not a cosmetic front end.
Routing errors also matter. If the selected organisation maps to the wrong identity provider, the federation flow may land on the wrong trust relationship, fail open in a poorly designed implementation, or create confusion that users resolve by retrying on an attacker-controlled page. Logging failed lookups, failed routing decisions, and unusual selection patterns helps defenders spot abuse, misconfiguration, or upstream identity-provider issues.
Defensive design should assume that attackers will probe the discovery page as a reconnaissance target. The page can reveal which organisations exist, how they are named, and which federated login paths are available. Even when no credentials are exposed directly, that information can still support spear phishing, tenant targeting, and help-desk impersonation.
What good implementation looks like
A strong implementation keeps the discovery experience narrow and predictable. It should use authoritative organisation records, accept only valid selections, and avoid letting user input drive arbitrary redirects. The display names should be clear enough for real users, but not so loose that trivial lookalikes, misleading aliases, or ad hoc entries can be introduced without review.
It also helps to align the discovery page with the rest of the federation estate. If the discovery experience does not match the identity provider branding, domain naming, or expected sign-in route, users have no reliable cue for whether they are on the real flow. Consistency across the discovery page, federation metadata, and login branding reduces the chance that users accept a counterfeit page as normal. NHIMG’s Identity Provider and SSO Security Guide is useful background for the wider trust, session, and federation controls around this flow.
Good operators also monitor the discovery stage as a separate event stream, not only the final authentication outcome. That means tracking abandoned selections, repeated lookup failures, odd organisation-name probes, and spikes in misroutes. In federation environments, discovery telemetry can be one of the earliest signs that a legitimate sign-in flow is being cloned or manipulated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Organisation discovery directly precedes user authentication routing. |
| AU-2 — Audit Events | Routing failures and misuse should be logged as security events. | |
| AC-3 — Access Enforcement | The discovery step determines which identity provider and access path is enforced. | |
| Recommendation — Protect the sign-in path by enforcing strong identification and authentication before federated access is granted. Define and retain discovery-stage events so anomalous routing and misuse can be investigated. Enforce validated routing rules so only approved federation paths can be selected. | ||
Practitioner Guidance
What to verify: Confirm that organisation names are sourced from a controlled directory or federation registry, and that selection cannot be altered by arbitrary query parameters or client-side manipulation. If the page accepts free text instead of a validated list, treat that as a design defect, not a UX choice.
Decision rule: If a user can reach the wrong identity provider from the discovery page, the routing logic is too permissive. Tighten the mapping first, then review branding, logging, and anti-phishing cues; do not wait for a phishing incident to prove the flaw.
What practitioners underestimate: Discovery pages often look harmless, so they receive less review than the main login page. In practice, they can become the most spoofed part of the sign-in journey because they are early, familiar, and trusted by users who expect to make a selection there.
Practitioner takeaway: Treat home-organisation discovery as a federated trust control, not a convenience feature, because the main risk is not only failed routing but attacker-controlled impersonation of the routing step itself.
Related resources from NHI Mgmt Group
- How do you know if remote work security controls are actually working?
- How do you know if access controls are too friction-heavy to work in practice?
- How do you know whether AI is improving team productivity or just shifting work around?
- How do you know if your outage recovery plan will actually work?