Configuring Office 365 Federation for external users to access SharePoint Online resources

%3CLINGO-SUB%20id%3D%22lingo-sub-2864842%22%20slang%3D%22en-US%22%3EConfiguring%20Office%20365%20Federation%20for%20external%20users%20to%20access%20SharePoint%20Online%20resources%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2864842%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%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-2864842%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3ESharePoint%20Online%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%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

0 Replies