Configuring Office 365 Federation for external users and native Office 365 auth for internal users

%3CLINGO-SUB%20id%3D%22lingo-sub-2864897%22%20slang%3D%22en-US%22%3EConfiguring%20Office%20365%20Federation%20for%20external%20users%20and%20native%20Office%20365%20auth%20for%20internal%20users%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2864897%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20want%20external%20users%20to%20federate%20external%20users%20authentication%20in%20Office%20365%20with%20an%20external%20identity%20provider.%20The%20authentication%20provider%20is%20not%20implemented%20by%20us.%20The%20goal%20is%20to%20enable%20both%20internal%20and%20external%20users%20to%20access%20Office%20365%20resources%2C%20namely%20SharePoint%20Online.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIs%20it%20possible%20to%20have%20internal%20users%20authenticate%20using%20native%20Office%20365%20authentication%20(using%20URL%20%3CA%20href%3D%22https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noreferrer%22%3Ehttps%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%3C%2FA%3E%2C%20going%20against%20Azure%20AD%20directly)%20and%20have%20external%20users%20to%20be%20authenticated%20against%20na%20external%20identity%20provider%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAccording%20to%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fexternal-identities%2Fdirect-federation%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fexternal-identities%2Fdirect-federation%3C%2FA%3E%2C%20a%20domoin%20must%20be%20configured%20as%20being%20federated%20and%20thus%20a%20user%20must%20enter%20a%20email%20in%20the%20default%20Office%20365%20login%20page%20(%3CA%20href%3D%22https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noreferrer%22%3Ehttps%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%3C%2FA%3E)%20from%20the%20domain%20that%20is%20going%20to%20be%20federated%20so%20that%20the%20authentication%20can%20be%20done%20in%20the%20external%20identity%20provider%20page%20(user%20gets%20redirected%20if%20it%20enters%20na%20email%20from%20the%20federated%20domain).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20our%20case%2C%20we%20would%20like%20to%20have%3A%3C%2FP%3E%3COL%3E%3CLI%3E%3CSPAN%3EInternal%20users%20to%20authenticate%20against%20Azure%20AD%20login%20page%20(%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noreferrer%22%3E%3CSPAN%3Ehttps%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%3C%2FSPAN%3E%3C%2FA%3E%3CSPAN%3E)%3C%2FSPAN%3E%3C%2FLI%3E%3CLI%3E%3CSPAN%3EExternal%20users%20(if%20possible%2C%20without%20any%20email%20introdution%2C%20not%20sure%20if%20possible)%20to%20go%20to%20an%20external%20identity%20provider%20for%20authentication%20and%20authorization.%20This%20identity%20provider%20has%20authentication%20mechanisms%20that%20dont%20rely%20on%20email%20but%20on%20other%20Personal%20Identification%20Information%20such%20as%20VAT%20Number%20for%20instance.%3C%2FSPAN%3E%3C%2FLI%3E%3C%2FOL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EQuestions%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3COL%3E%3CLI%3E%3CSPAN%3EWill%20users%20always%20pass%20through%20the%20Azure%20AD%20login%20page%20(%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noreferrer%22%3E%3CSPAN%3Ehttps%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%3C%2FSPAN%3E%3C%2FA%3E%3CSPAN%3E)%3F%3C%2FSPAN%3E%3C%2FLI%3E%3CLI%3E%3CSPAN%3EIf%20yes%2C%20how%20can%20we%20differentiate%20internal%20users%20from%20external%20users%3F%20Through%20the%20domain%3F%20Examples%3A%3C%2FSPAN%3E%3C%2FLI%3E%3COL%3E%3CLI%3E%3CSPAN%3EDomain.com%20-%20auth%20done%20directly%20in%20Azure%20AD%20without%20any%20redirection%20to%20custom%20identity%20provider%3C%2FSPAN%3E%3C%2FLI%3E%3CLI%3E%3CSPAN%3EExternaldomain.com%20-%20domain%20configured%20as%20federated%20and%20thus%20being%20redirect%20to%20the%20custom%20login%20page%20from%20the%20identity%20provider%3C%2FSPAN%3E%3C%2FLI%3E%3C%2FOL%3E%3CLI%3E%3CSPAN%3EIf%20no%2C%20how%20can%20we%20ensure%20that%20internal%20users%20go%20though%20the%20normal%20Azure%20AD%20authentication%20flow%20and%20external%20users%20go%20thought%20the%20custom%20login%20page%20from%20the%20identity%20provider%3F%3C%2FSPAN%3E%3C%2FLI%3E%3CLI%3E%3CSPAN%3ESince%20the%20custom%20identity%20provider%20has%20authentication%20mechanisms%20that%20dont%20rely%20on%20email%20but%20on%20other%20Personal%20Identification%20Information%20such%20as%20VAT%20Number%20for%20instance%2C%20how%20can%20we%20ensure%20that%20the%20returned%20identity%20can%20be%20mapped%20to%20a%20valid%20Guest%20User%20in%20Azure%20AD%20that%20requires%20an%20email%3F%3C%2FSPAN%3E%3C%2FLI%3E%3CLI%3E%3CSPAN%3EFrom%20my%20understanding%2C%20the%20Guest%20user%20in%20Azure%20AD%20must%20be%20created%20after%20authentication%20in%20the%20custom%20login%20page%20from%20the%20identity%20provider.%20How%20can%20we%20ensure%20that%20after%20authentication%20in%20the%20custom%20login%20page%20from%20the%20identity%20provider%2C%20the%20Guest%20User%20is%20created%20with%20a%20valid%20email%20address%3F%20The%20identity%20provider%20must%20supply%20a%20valid%20email%20(assuming%20email%20is%20available)%20to%20a%20custom%20page%20of%20ours%20that%20invokes%20the%20Create%20invition%20(%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fgraph%2Fapi%2Finvitation-post%3Fview%3Dgraph-rest-1.0%26amp%3Btabs%3Dhttp%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3E%3CSPAN%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fgraph%2Fapi%2Finvitation-post%3Fview%3Dgraph-rest-1.0%26amp%3Btabs%3Dhttp%3C%2FSPAN%3E%3C%2FA%3E%3CSPAN%3E)%20API%3F%3C%2FSPAN%3E%3C%2FLI%3E%3CLI%3E%3CSPAN%3EIs%20it%20possible%20to%20have%20a%20custom%20form%20to%20override%20%3C%2FSPAN%3E%3CA%20href%3D%22https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noreferrer%22%3E%3CSPAN%3Ehttps%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize%3C%2FSPAN%3E%3C%2FA%3E%3CSPAN%3E%20or%20the%20authentication%20entry%20point%20is%20always%20the%20the%20MS%20login%20page%20and%20the%20user%20has%20to%20enter%20a%20domain%20(the%20federated%20domain)%20in%20the%20MS%20login%20page%20to%20be%20redirected%20to%20the%20identity%20provider%20custom%20page%20for%20authentication%20and%20authorization%3F%3C%2FSPAN%3E%3C%2FLI%3E%3CLI%3E%3CSPAN%3EAny%20more%20relevant%20details%20in%20the%20process%3F%3C%2FSPAN%3E%3C%2FLI%3E%3CLI%3E%3CSPAN%3EWhat%20is%20the%20most%20complete%20guide%20available%20with%20all%20the%20steps%20necessary%20for%20this%20scenario%3F%3C%2FSPAN%3E%3C%2FLI%3E%3C%2FOL%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2864897%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAdmin%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3Eidentity%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2865183%22%20slang%3D%22en-US%22%3ERe%3A%20Configuring%20Office%20365%20Federation%20for%20external%20users%20and%20native%20Office%20365%20auth%20for%20internal%20use%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2865183%22%20slang%3D%22en-US%22%3EHello%2C%3CBR%20%2F%3E%3CBR%20%2F%3EIf%20it%20is%20for%20B2B%2C%20you%20should%20have%20a%20look%20at%20Azure%20B2B%20Collaboration%20%3A%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fexternal-identities%2Fwhat-is-b2b%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fexternal-identities%2Fwhat-is-b2b%3C%2FA%3E%3CBR%20%2F%3E%3CBR%20%2F%3EIn%20short%2C%20Azure%20B2B%20enable%20to%20federate%20the%20authentication%2C%20to%20let%20you%20to%20invite%20external%20user%20as%20guest%20in%20your%20tenants.%20They%20will%20be%20able%20to%20consume%20your%20services%20(e.g.%2C%20SharePoint%20Online)%20with%20their%20identity%20(and%20so%20their%20IdP).%3CBR%20%2F%3E%3CBR%20%2F%3EAll%20the%20guests%20users%20will%20have%20a%20specific%20UPN%20%3A%3CBR%20%2F%3E-%20If%20userA%40contoso.com%20is%20invited%3CBR%20%2F%3E-%20His%20UPN%20will%20be%20%3A%20userA_contoso.com%23ext%23%40yourconompany.onmicrosoft.com%3CBR%20%2F%3E%3CBR%20%2F%3EIn%20any%20case%2C%20the%20authentication%20to%20Azure%20AD%20goes%20through%20login.microsoftonlin.com%20or%20login.live.com%3CBR%20%2F%3E%3CBR%20%2F%3E%3CBR%20%2F%3EIf%20it%20is%20for%20B2C%2C%20you%20should%20have%20a%20look%20at%20B2C%3CBR%20%2F%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory-b2c%2Foverview%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory-b2c%2Foverview%3C%2FA%3E%3C%2FLINGO-BODY%3E
Occasional Contributor

Hi,

 

I want external users to federate external users authentication in Office 365 with an external identity provider. The authentication provider is not implemented by us. The goal is to enable both internal and external users to access Office 365 resources, namely SharePoint Online.

 

Is it possible to have internal users authenticate using native Office 365 authentication (using URL https://login.microsoftonline.com/common/oauth2/v2.0/authorize, going against Azure AD directly) and have external users to be authenticated against na external identity provider?

 

According to https://docs.microsoft.com/en-us/azure/active-directory/external-identities/direct-federation, a domoin must be configured as being federated and thus a user must enter a email in the default Office 365 login page (https://login.microsoftonline.com/common/oauth2/v2.0/authorize) from the domain that is going to be federated so that the authentication can be done in the external identity provider page (user gets redirected if it enters na email from the federated domain).

 

In our case, we would like to have:

  1. Internal users to authenticate against Azure AD login page (https://login.microsoftonline.com/common/oauth2/v2.0/authorize)
  2. External users (if possible, without any email introdution, not sure if possible) to go to an external identity provider for authentication and authorization. This identity provider has authentication mechanisms that dont rely on email but on other Personal Identification Information such as VAT Number for instance.

 

Questions:

 

  1. Will users always pass through the Azure AD login page (https://login.microsoftonline.com/common/oauth2/v2.0/authorize)?
  2. If yes, how can we differentiate internal users from external users? Through the domain? Examples:
    1. Domain.com - auth done directly in Azure AD without any redirection to custom identity provider
    2. Externaldomain.com - domain configured as federated and thus being redirect to the custom login page from the identity provider
  3. If no, how can we ensure that internal users go though the normal Azure AD authentication flow and external users go thought the custom login page from the identity provider?
  4. Since the custom identity provider has authentication mechanisms that dont rely on email but on other Personal Identification Information such as VAT Number for instance, how can we ensure that the returned identity can be mapped to a valid Guest User in Azure AD that requires an email?
  5. From my understanding, the Guest user in Azure AD must be created after authentication in the custom login page from the identity provider. How can we ensure that after authentication in the custom login page from the identity provider, the Guest User is created with a valid email address? The identity provider must supply a valid email (assuming email is available) to a custom page of ours that invokes the Create invition (https://docs.microsoft.com/en-us/graph/api/invitation-post?view=graph-rest-1.0&tabs=http) API?
  6. Is it possible to have a custom form to override https://login.microsoftonline.com/common/oauth2/v2.0/authorize or the authentication entry point is always the the MS login page and the user has to enter a domain (the federated domain) in the MS login page to be redirected to the identity provider custom page for authentication and authorization?
  7. Any more relevant details in the process?
  8. What is the most complete guide available with all the steps necessary for this scenario?

 

Thanks

2 Replies
Hello,

If it is for B2B, you should have a look at Azure B2B Collaboration : https://docs.microsoft.com/en-us/azure/active-directory/external-identities/what-is-b2b

In short, Azure B2B enable to federate the authentication, to let you to invite external user as guest in your tenants. They will be able to consume your services (e.g., SharePoint Online) with their identity (and so their IdP).

All the guests users will have a specific UPN :
- If userA@contoso.com is invited
- His UPN will be : userA_contoso.com#ext#@yourconompany.onmicrosoft.com

In any case, the authentication to Azure AD goes through login.microsoftonlin.com or login.live.com


If it is for B2C, you should have a look at B2C
https://docs.microsoft.com/en-us/azure/active-directory-b2c/overview
Hi,

Thanks for the info.
In our case, the invite seems not to be an option since the external identity provider is based on Oracle and the available auth methods don't rely on email.

External users will have to log in using one of the following methods:
- VAT Number and password (auth against a external system)
- Generic auth system that uses mobile number and MFA auth
- Internal form with user (not sure what this is yet) and password

How can invite and B2B work here?

Please take a look at all details I explain in the initial question.

Tks
Miguel