In the picture above, you can see how Conditional Access will evaluate those guest users.
The majority of users who are typically thought of as guests fall into this category. This B2B collaboration user has guest-level access in your organization and an account in an external Azure AD organization or external identity provider. The UserType of the user object created in your Azure AD directory is Guest. Users of B2B collaboration who have been invited and signed up through self-service fall under this category.
Did you know that SAML/WS-Fed identity provider (IdP) federation was called Direct federation before?
No, no worries. Let’s see what it all about and how to connect our SAML to it in the first part of this series.
Table of Contents
What are External Identities in AAD?
All the secure communication channels you can utilize with users outside of your business are referred to as Azure AD External Identities. You can share your resources and specify how internal users can access other businesses if you wish to work with partners, distributors, suppliers, or vendors. Developers who make consumer-facing apps have control over their users’ identity experiences.
External users can “bring their own identities” with the help of External Identities. They can sign in using their own credentials regardless of whether they have a digital identity that was granted by a company, the government, or an unmanaged social identity like Google or Facebook. To safeguard your resources, the external user’s identity provider handles their identity while you control access to your apps using Azure AD or Azure AD B2C.
External Identity providers
There are several different types of External identity providers and types and many of them you you can relatively easy integrate to with Azure AD
Azure Active Directory accounts
Guests can complete your sign-up user processes and redeem your B2B collaboration invitations using their Azure AD work or school accounts. One of the default permitted identity providers is Azure Active Directory. This identity provider can be used for user flows without any additional configuration.
Microsoft accounts
Invites for B2B cooperation can be redeemed by guest users using their own personal Microsoft accounts (MSA). You can add Microsoft Account as one of the permitted identity providers when configuring a self-service sign-up user flow. This identity provider can be used for user flows without any additional configuration.
Email one-time passcode
A guest user may ask for a temporary code, which is provided to their email address, in order to redeem an invitation or access a shared resource. They then input this code to carry on with sign-in. When other methods of authentication fail, the email one-time passcode function authenticates B2B visitor users. You can include Email One-Time Passcode as one of the authorized identity providers when configuring a self-service sign-up user flow.
Using their personal Gmail accounts to log into your apps, third parties can redeem invitations from you thanks to Google Federation. Your self-service sign-up user flows can also leverage Google federation.
To allow users to sign up for your app using their personal Facebook accounts, you can configure self-service sign-up and enable Facebook federation when creating an app. Facebook is not an option for sign-in when users are using your invitations; it can only be utilized for self-service sign-up user journeys. Check out the steps for adding Facebook as an identity provider.
And let’s draw the line here, all the above are the “easy” ones, well at least public IdP’s are easier than on-premise ones. SAML or WS-Fed means this for many.
SAML/WS-Fed identity provider federation
You can also set up federation with any external IdP that supports the SAML or WS-Fed protocols. SAML/WS-Fed identity provider federation. External users can redeem invitations from you using the SAML/WS-Fed IdP federation by logging into your apps with their already social or business credentials.
Here is a supporting workflow from Microsoft to show should you choose SAML or something else?
How to setup SAML IdP?
First you need to have you SAML based IdP in-place, almost any external publicly available Identity will do just fine and you need the following Attributes to be provided to Azure AD in the response.
| Attribute | Value |
|---|---|
| AssertionConsumerService | https://login.microsoftonline.com/login.srf |
| Audience | https://login.microsoftonline.com/<tenant ID>/ (Recommended) Replace <tenant ID> with the tenant ID of the Azure AD tenant you’re setting up federation with.In the SAML request sent by Azure AD for external federations, the Issuer URL is a tenanted endpoint (for example, https://login.microsoftonline.com/<tenant ID>/). For any new federations, we recommend that all our partners set the audience of the SAML or WS-Fed based IdP to a tenanted endpoint. Any existing federations configured with the global endpoint (for example, urn:federation:MicrosoftOnline) will continue to work, but new federations will stop working if your external IdP is expecting a global issuer URL in the SAML request sent by Azure AD. |
| Issuer | The issuer URI of the partner’s IdP, for example http://www.example.com/exk10l6w90DHM0yi... |
And the only one required claim for the SAML 2.0 token issued by the IdP
| Attribute Name | Value |
|---|---|
| NameID Format | urn:oasis:names:tc:SAML:2.0:nameid-format:persistent |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress | emailaddress |
Quick tip! You can use Microsoft Metadata Explorer to find out how your ADFS in looking outside
Once you have these setup, you can add the IdP to Azure AD, you can do it here https://entra.microsoft.com/#view/Microsoft_AAD_IAM/CompanyRelationshipsMenuBlade/~/IdentityProviders/menuId/IdentityProviders
And no, it has to be the same suffix
But if you want, you can use it. You just need to add an TXT-records to your public DNS that will point the SAML IdP that you want to use, like this in my example, adding the record that point to my Federation Passive Endpoint.
|
1 |
DirectFedAuthUrl=https://adfs.cloudpartnerdemo.fi/adfs/ls |
And you should see it like this
And success!
If you are trying to add an Azure AD verified domain, it will fail. The error it will be clearly saying why.
But in a tenant you have it verified it will give a little bit misleading error.
Now you can see one domain under SAML IdP, well let’s add another one if needed.
SAML based invitation redemption
The user will receive the invitation email and click the link, this will start a workflow as follows.
Put we can also use that Invitation API to generate a invite and cheat a bit if needed. You can copy paste the invitation link from the results.
Invitation API
The invitation process uses the following flow:
- An invitation is created
- An invitation is sent to the invited user (containing an invitation link)
- The invited user clicks on the invitation link, signs in and redeems the invitation and creation of the user entity representing the invited user completes
- The user is redirected to a specific page after redemption completes
And in the response you see the redemption URL and other valuable information.
Now we can see the user is still in PendingAcceptance state
Token protection (preview)
One excellent new feature for protecting your user from harm is Token protection, you can find it under Conditional access -> Session
But it doesn’t support B2B user as of now but take a note of it and keep it in considerations when developing those policies.
Closure
That was the setup, in the next part we will see how this all will be seen for the user and what’s to come on Azure AD but also what you could choose differently.
I have had some feedback from the community that I wrote too long posts, so will cut this in half, in any case these are made for you all, thanks for the feedback! Have a good one!
RSS - Posts