Azure AD B2B collaboration direct federation with SAML and WS-Fed providers now in public preview

Published 07-08-2019 09:00 AM 29K Views

Howdy folks,


We’ve been making it easier to work with your partners by enabling you to collaborate with them using their existing identities, regardless of whether they use Azure AD or not. We already support Google social IDs as well as any email account. As a next major step in this direction, I’m excited to announce that we have a new capability—direct federation—now in public preview!


Direct federation makes it easier for you to work with partners whose IT managed identity solution is not Azure AD. It works with identity systems that support the SAML or WS-Fed standards. When you set up a direct federation relationship with a partner, any new guest user you invite from that domain can collaborate with you using their existing organizational account. This makes the user experience for your guests more seamless.


With direct federation, your guest users sign in with their organizational account, satisfying any security requirements that your partner organization has already implemented. Any additional security controls you implement for guest users, such as stronger proof of ownership for Multi-Factor Authentication (MFA), also applies to these users. When your guest leaves their organization, they no longer have access to resources.



Figure 1. User authentication journey using direct federation.Figure 1. User authentication journey using direct federation.


Let’s walk through what happens when a user signs in with direct federation:

  1. The direct federation user clicks a link to an application or resource you have shared with them.
  2. Azure AD checks to see if the user has been invited. 
  3. The user is re-directed to their identity provider for sign-in. 
  4. After successful sign-in, the user is returned to Azure AD. 
  5. Azure AD validates the token then sends the user to app for access. (Figure 1)  

Watch this video to learn more about how direct federation works and other identities we support.


Figure 2. Setting up direct federation in Azure AD—Organizational relationships.Figure 2. Setting up direct federation in Azure AD—Organizational relationships.

To try direct federation in the Azure portal,  go to Azure Active Directory > Organizational relationships - Identity providers, where you can populate your partner’s identity provider metadata details by uploading a file or entering the details manually. (Figures 2 and 3) During public preview, we only support direct federation with an identity provider whose authentication URL matches the target domain for direct federation or belongs to a standard identity provider.


Figure 3. Populating direct federation metadata in Azure AD.Figure 3. Populating direct federation metadata in Azure AD.

Go ahead and dive into the documentation to try out direct federation and learn more! Let us know what you think by taking our brief survey.


And as always, connect with us for any discussion or send us your feedback and suggestions. You know we’re listening! 


Best regards,


Alex Simons (@Alex_A_Simons )

Corporate VP of Program Management

Microsoft Identity Division

Frequent Visitor

Hi Alex, great article and nice to have this capabilities at AAD level however, how will be the deletion of those Guest accounts that no longer can authenticate by their identity provider? is there any mechanism that will keep clean and tidy the AAD for guest accounts?

Hi Gamaliel -


Great question. Azure AD Access Reviews and Entitlement Lifecycle Management are both great options for automating the review and/or removal of guest accounts from you tenant. I would recommend getting started by reading this blog post from a few months back:


Best Regards,



Great stuff, keep it coming! Been waiting for this feature. Will surely be a choice for many of our customers!


Great improvement. Is there any way to merge the existing guest accounts (Microsoft accounts) into the direct federation account? e.g (MS account)has access to a shared app within contoso. Now contoso has direct federation with AD , how will the existing behave?




Does this resolve the previous issues with Gmail authentication integration where users visiting non-tenant specific login pages (e.g. could not log in?

Frequent Visitor

Hi Alex, nice work!  Couple of questions...


1. how does role and attribute mapping work in this model?  I assume the 3rd party IDP is just for identity, and the Azure Enterprise App is still used for the authorisation and SAML token attribute mapping?


2. do you need the 3rd parties IDP metadata?  Is it a formal SAML (metadata exchanged) relationship?




Senior Member

This is a really exciting feature!


Can we use this to federate with another Azure AD tenant? We work very closely with them and need to give their users access to some of our apps, the guest accounts work for now but there is a scale issue.




@Phillip Lyle Direct federation users can also only be able to authenticate at a tenanted endpoint currently. We are working on a solution for these users to authenticate at the common endpoint.

@unnie ayilliath There's currently no easy way to merge accounts or convert an existing account's authentication method to another. We are working on a solution that would make the latter for guests easier.

@Weston Woolworth You cannot use direct federation for federating with a domain that is DNS verified on Azure AD (ie. another Azure AD tenant). Direct federation was designed for collaboration from an Azure AD tenant to another org that is not Azure AD.

Regular Visitor

Indeed this is great Alex, but I see in the documentation ( that it does not support verified domain names. Is this a long-term limitation or will there be an update soon. Any large customer that would like to use this will most definitely have a verified domain name in Azure. Any help you can offer would be great!:smile:


@NRuest can you elaborate on your scenario where you need to federate with a verified domain on Azure AD? Note that direct federation is meant to support federation with external orgs who you're collaborating with. There are orgs you may work with whose domains may be verified on Azure AD; I would like to make sure we're talking about the same scenario.

Regular Visitor

Thanks @Maria_Lai. From what I understand, if my organization has a verified domain name such as Contoso.Com in Azure, then I cannot use direct federation. I may be wrong, but when I first obtain a subscription in Azure, my domain becomes When I add my verified DNS domain,, to my subscription, it becomes a verified domain. 


The documentation in the link I mentioned clearly states that direct federation does not work with verified DNS names. Does that apply to me as or does that apply to my partners, such as who would have verified their names in Azure? 


To be clear, my goal is to have multiple partners (possibly over 100) interact with single sign on through direct federation in an Azure AD-based B2B environment to facilitate the use of resources that are accessed through this iteration of Azure AD. Am I going about this the right way?


Thanks @NRuest. "Does that apply to me as or does that apply to my partners, such as who would have verified their names in Azure?" This restriction applies to your partners, whom you're federating with. I'll update the doc to be more clear. As long as your partners' domains are not DNS verified on Azure AD (and they pass the other restrictions during public preview), you will be able to federate with them.

How many users from each partner you might federate with do you expect to come into your tenant?

Regular Visitor

@Maria_LaiThanks Maria. That does make it clearer. So if my domain is verified, it is OK. That is great. However, some of my partners will have verified DNS names because they will have their own Azure subscriptions. Can you confirm that for these partners, we won't need to use direct federation? We could use an Azure subscription to Azure subscription federation? For the others, we would be OK with non-verified names. As for the number of users from each partner, it would be small at first but it will gradually increase as time goes by as our partners become familiar with our applications and begin to embrace the solution we have in place for them. 


I really appreciate your responses BTW.

New Contributor

HI Alex, Maria


We are exactly looking for same setup for our organisation, Direct federation with SAML for multiple IDP provider.


To try this configuration, i first started with our ADFS IDP which is configured in our On-premise VM.


I have updated our on-premise ADFS configuration as per this document -

Next, when i am trying to setup "Azure AD B2B collaboration direct federation with SAML", in Azure portal as mentioned above steps,  i get error "Failed to add a SAML/WS-Fed identity provider" when i click Save Button.


There is no further explanation, error logs to troubleshoot further.


@Alex_A_Simons , @Maria_Lai , @Alex Simons (AZURE) Please advise how to identify the issues and setup this configuration. 




Regular Visitor

Looks interesting.

If multiple (SAML / WS-Fed) IdP's are configured, how does the Azure AD direct federation functionality know to which IdP it should redirect the user for authentication ?

Regular Visitor

Hi PJ, you define the IdPs in the Azure Organizational Relationships -- Identity Providers interface, so Azure AD knows which IdP to go to based on your own definitions in the portal. Pretty cool functionality if you ask me. 

Regular Visitor

Hi @NRuest 

I don't understand.

What if I define 5 IdP's in the Azure Organizational Relationships -- Identity Providers interface.

I invite a new user and the user accepts the invitation (during this process the user is not pinned to one of the IdP's)

How does Azure AD direct federation functionality know to which of the 5 IdP's it should redirect the user for authentication when the user accepts the invitation ?

Second complication : What can or should happen if this user has an account at 2 or more of the 5 IdP's ?

Regular Visitor

Hi PJ. If you look at the diagram in Figure 1, you'll see that everything is based on the invitation you send to the user. This invitation will identify which IdP is to be used. Does that help?

Regular Visitor

Hi @NRuest ,

OK, now I understand where the limitation is.

Figure 1 assumes that the users is always equal to the domain used to configure the IdP, , because that is not necessarily true in all cases.

I have at least one IdP, with a directory behind it that contains mixed B2B identities with users from a (non-limited) set of domains in their userId/email address.

So, that's not going work with this setup.

Because the domain of the IdP is, for instance,, but the users identify themselves with …, … etc.

Senior Member

Tested this today with a self-contained domain (no internet access to it, users access ADFS IdP via private connection) and it works like a charm. Only real, dependencies is the URL requirement (ADFS URL must be within the domain you are federating with, eg. if federating with TestDomain.local then ADFS must be something like adfs.testdomain.local), and that the domain must not be verified on any tenant.




How federated domain users can access the applications of Azure AD when federated domain is third party IDP i.e. Onelogin?

Occasional Visitor

Hi folks


May someone confirm whether Direct Federation can be used to connect Azure AD to another Azure AD tenant?  

Would like some users in a MS365 Education tenant to have access to resources in separate corporate tenant.  Both tenants are owned by same organization.  Is there another better way to do this?




Version history
Last update:
‎Aug 03 2020 01:50 PM
Updated by: