Business Context
The platform already supported modern authentication at selected boundaries, but important journeys still assumed that a user had a Windows account in the managed domain. That assumption reached beyond the initial sign-in: document creation and Follow-me printing also depended on a reliable user identity being available to downstream services.
Microsoft Entra External ID introduced users who did not belong to the corporate Active Directory domain or participate in the managed Windows environment. The goal was to provide an end-to-end SSO journey across tenant and service boundaries, not simply a separate login screen.
Goal
Provide full SSO for users outside the Windows domain
The goal was to support identities from a customer-owned Entra External ID tenant across an ISV-owned tenant hosting the user interface and APIs. Windows AD access control could not be applied to external users, and OAuth-authenticated services could not convert OAuth credentials to Kerberos without a custom authentication method. Cross-tenant synchronisation, MFA and application permissions therefore needed to work as one governed journey.
Downstream services also had to participate in that journey. Document services needed to accept OAuth-protected calls and receive sufficient user identity context for document creation and Follow-me printing, without requiring an equivalent Windows account to be manufactured for each external user.
Method
Make tenant trust and service identity explicit
The identity design distinguished the source tenant, the synchronised identity relationship and the stable application-level user. Cross-tenant synchronisation connected the customer-owned identity domain to the hosted application domain while keeping tenant ownership and security boundaries explicit.
Application registrations, service principals, permission grants and RBAC assignments represented the hosted UI, APIs and service identities. MFA remained an identity-platform responsibility so that established application components did not have to implement modern identity controls themselves.
The downstream document path was then updated to use OAuth. User identity context accompanied document-creation requests so that the service could perform work for the authenticated user and retain the context required by the Follow-me printing journey.
Windows identity remained a deliberate compatibility path for services that still required it. This allowed externally authenticated journeys to be introduced without forcing every domain-dependent component to change at the same moment.
Technical Challenges
Keep identity and permissions coherent across the whole journey
A user being able to sign in was only the first boundary. The platform also needed to know which tenant the identity came from, how the synchronised account mapped to the application user, which permissions applied, and how that identity should be represented when an API called another service.
Document creation and Follow-me printing needed verified user details even when the authenticated person did not have a Windows account. The hosted UI, APIs and downstream services therefore had to pass and interpret user context consistently, while domain-based integration remained available for components that still required it.
Permissions also spanned Entra and application boundaries. Ownership boundaries had to be defined around application permissions so that Entra assignments and application-controlled assignments remained aligned. Some established application permissions could not be enforced through Entra RBAC or app-role assignments, so the overlap had to be understood and incorporated into operational support processes.
Outcomes
External users could complete authenticated end-to-end journeys
The platform gained a route for external users to authenticate through Microsoft Entra External ID, reach hosted UI and APIs across tenant boundaries, and continue into OAuth-enabled downstream document services.
External identities could be represented without creating equivalent internal Windows users. At the same time, services that still relied on domain-integrated behaviour could continue operating while their boundaries were modernised in controlled stages.
Business benefits
Extend access without weakening control
- Full SSO journeys for users outside the managed Windows domain.
- Clear ownership of customer and hosted identity tenants.
- Cross-tenant identity relationships kept visible and governable.
- MFA and token issuance retained at the identity-platform boundary.
- OAuth support extended into document creation and Follow-me printing journeys.
- Continued operation of domain-dependent capabilities during staged modernisation.
Architecture value
Architecture kept external access governable
A successful login would not, by itself, have delivered the required service journey. Architecture connected tenant ownership, synchronised identity, application permissions and downstream user context into one supportable model. It enabled external access without weakening control or forcing every domain-dependent capability to change at once.
Discuss your project
Extending identity beyond one tenant?
If you need to support external users, cross-tenant SSO or delegated identity across downstream services, contact me to discuss the trust boundaries, application changes and transition stages involved.
Contact me about a modernisation project