In this part we will see the end-user experience and what you could use instead of Direct federation.
SAML-based External IdP can be also done with federating your cloud-based domains. The idea and the concept is the same but in this case the domains are completely outside. You can either use ADFS for this or maybe even external IdP, see more here.
But as the mentioned one will federate a whole domain, let’s continue the route we had chosen and see what it looks like for the users.
Table of Contents
End-user experience
Guest users sign into your Azure AD tenancy using their own organizational account when utilizing SAML/WS-Fed IdP federation.
- Users are sent to their IdP when they attempt to access shared resources and are requested to check in.
- Users are taken back to Azure AD to access resources after a successful sign-in.
- The user encounters SSO if the federated IdP has SSO enabled and the Azure AD session ends or becomes invalid.
- The user is not required to sign in again if the federated user’s session is still active. If not, the user is sent to their IdP to sign in.
User logins to their IdP with their own credentials
And approve consents (you can also define these in the Invitation API)
After this process you will see the user invitation as Accepted
And we can see the user is Federated, wuhuu!
Then I add the user to my Enterprise application, which in this case is AADClaimsXray, it works like jwt.ms page but will give you the information little bit more graphically.
If you are using in example ADFS, you will be presented the familiar login screen and redirected to the application. Email address was the only claim that I modified for this demo.
And you also access https://myapps.microsoft.com but you have to add an verified domain domain behind it or Tenant GUID, so login will be redirected to a correct place.
Like this https://myapps.microsoft.com/cloudpartnerdemo.fi
What doesn’t work with SAML?
Two things that we have anything to do with this scenario:
- For Azure AD verified domains, Microsoft will disable SAML/WS-Fed IdP federation in favor of native Azure AD managed domain features. An issue occurs when you attempt to set up SAML/WS-Fed IdP federation with a domain that is DNS-verified in Azure AD.
- You cannot use self-service sign-up the federated users, you have to invite them as guest, one by one or in Bulk, in example with the Invitation API
What’s new?
There is always something as Microsoft Cross all features keep growing all the time. Microsoft has one the most comprehensive suites to support cross-platform, cross-cloud and even cross-tenants scenarios.
What will deprecated?
On the other hands, something has to go.
| Functionality, feature, or service | Change | Change date |
| Microsoft Authenticator app Number matching | Feature change | May 8, 2023 |
| Azure AD DS virtual network deployments | Retirement | Mar 1, 2023 |
| License management API, PowerShell | Retirement | *Mar 31, 2023 |
| Azure AD Authentication Library (ADAL) | Retirement | Jun 30, 2023 |
| Azure AD Graph API | Deprecation | Jun 30, 2023 |
| Azure AD PowerShell and MSOnline PowerShell | Deprecation | Jun 30, 2023 |
| Azure AD MFA Server | Retirement | Sep 30, 2024 |
Other scenarios
See this full comparison of the situations you may allow with Azure AD External IDs is provided in the following table. Anybody who is not a member of your Azure AD organization is considered an external user in the B2B scenarios.
Microsoft Cross-tenant roadmap
When it comes to the cross-tenant access features, Microsoft has a strong road plan so far. There won’t be any more external users or jumping between Teams tenants when you require access to various tenants, which we all know you do.
You will only receive one prompt if you are using your own user account and the target tenant has given permission to trust your MFA. Several authentication strategies can satisfy authentication strength in circumstances involving external users, depending on whether the user is completing MFA in their home tenant or the resource tenant. The supported techniques are shown in the table below.
You can read from my previous blogs on the different features.
Workload identity federation
You may set up an Azure AD app registration or user-assigned managed identity to trust tokens from an external identity provider (IdP), such as GitHub, by using workload identity federation. After a trust relationship has been established, your software program may swap access tokens from the Microsoft identity platform for trusted tokens from an external IdP.
The Azure AD protected resources to which your software workload has been granted access can then be accessed using that access token. As a result, there is no longer a maintenance burden associated with manually handling credentials, and there is no longer a chance of secrets leaking or certificates expiring.
Custom claims provider (preview)
The following situations call for the use of a Custom claims provider:
- Migration of legacy systems – You may have existing data stores that include user information, such as LDAP directories, or legacy identity systems, such as Active Directory Federation Services (AD FS). Although you want to move these apps to Azure AD, you can’t fully transfer the identity data there. Your apps could be hard-coded to rely on certain information on the token.
- Integration with non-directory data storage – You can have internal systems or third-party systems that hold user data. In a perfect world, this data might be aggregated in the Azure AD directory, either by synchronization or direct migration. It isn’t always possible, though. The limitation could be brought on by rules, data residency, or other conditions.
Resource called @merill.net
And you should read this comparison from the one and only Merill Fernando aka Mr. Graph. From it you can see the comparison of the five different types of Microsoft Azure AD + Graph extensions and attributes.
Closure
That was Direct federation and some things to come in Azure AD. After reading this, would you do anything else differently?
Have an excellent week! It’s already have way!
RSS - Posts