My name is Samuel Devasahayam and I’m a Group Product Manager at Microsoft, focused on our Authentication platform. Over the past few years, we’ve seen thousands of customers migrate millions of apps and users from Active Directory Federation Services (AD FS) to Azure AD. Customers of all sizes have transformed their business by migrating apps to Azure AD and as a result no longer have to worry about supporting, patching, and monitoring the infrastructure associated with AD FS environments. Customers have also been able to reduce costs and improve their security posture. These migration efforts better protect organizations, enabling them to take full advantage of our industry-leading security capabilities in Azure AD such as multi-factor authentication, risk-based Conditional Access, Identity Protection and more.
Today, I’m thrilled to share several new and important capabilities to help customers easily migrate nearly ALL their applications from AD FS or other identity providers to Azure AD. We’re addressing several customer requests, such as improving claims and transformation capabilities that have prevented customers from migrating their apps to Azure AD. These new capabilities will help customers reduce their AD FS investments and provide them with industry-leading security capabilities in Azure AD. Read on to learn more about the investments we’ve made to make it easier to move all your apps from AD FS to Azure AD today.
In the early days of on-premises AD many customers had users that belonged to hundreds of groups that caused the Kerberos token to get too large, resulting in authentication failures for certain applications. Along came AD FS and federated applications, which provided a more thoughtful way to issue all those groups inside the SAML token – group filtering. This enabled customers to specify only the groups the application needed to make authorization decisions. As more customers matured into AD FS, they started doing more complex filtering with several input strings. Many customers even used group filtering to map AD groups to AWS roles.
We’ve now brought this capability to Azure AD! You can now filter the groups included in the SAML token using substring match on the display name or on the onPremisesSAMAccountName attribute of the group object. With this capability in public preview, organizations that have multiple group memberships can specify which groups are relevant to an application and only the groups a user is a member of will be included in the token.
As customers continue to adopt more SaaS applications, they often find that each application has different requirements for what user attributes (claims) must be transmitted in the SAML token. For example, some customers using Box will require that all the user’s proxyAddresses be included in the SAML token. However, this multi-valued attribute hasn’t been available in the Azure AD claims pipeline until now.
We’re now adding new user attributes as claims in Azure AD. These new attributes can be used as source when configuring Attributes & Claims in Azure Portal or in a claims mapping policy in Microsoft Graph, allowing you to move more applications from AD FS or other identity providers to Azure AD. Visit our claims mapping documentation to view all the new attributes now supported.
Many of our customers have configured their SaaS applications on AD FS to append additional data to user claims. For example, several customers have configured their usernames in Salesforce to contain the instance name (e.g. firstname.lastname@example.org) so when AD FS would issue the NameID claim, it would append the appropriate value to the end. Until now, this wasn’t possible in Azure AD because the NameID wasn’t allowed to contain a UPN domain (@domain.com) that wasn’t already verified in their tenant. With this new feature in public preview, you can now append data to the NameID without having that domain verified.
You can use the Join transformation function on NameID claim without domain verification. Now the Join transformation can be used on the NameID claim in the same way as any other claim and allows for more flexible transformations.
The Substring function is also now generally available in the claims configuration UI. Applications that need a claim created by extracting specific characters from a source attribute can now use the Substring function.
Earlier we mentioned how some customers need to send all the user’s proxyAddresses to applications like Box in the SAML token. From this same work, we learned that many customers first wanted to transform these proxyAddresses before including them in the token.
Claims transformations can also now be performed on multi-valued attributes and can emit multi-valued claims. This capability in public preview allows you to apply transformation on all items of the multi-valued claim instead of only the first item of an array.
As mentioned earlier, many customers are using group filtering to map AD groups into AWS roles, but many of those same customers also modify the group names to be consistent with AWS role nomenclature by using RegEx or RegEx Replace.
Azure AD now allows you to perform those same RegEx or RegExReplace transformations on group names. This capability can be used to perform group filtering based on multiple input strings. With multi-string group filtering and the flexibility of RegEx, one of our customers was recently able to move several of their AD FS applications directly to Azure AD. One large European transformation company told us, “This is great. The regex feature will benefit us greatly as we use Azure AD as our only SSO provider. Great work!”
We hope you enjoy these new updates that make it easier to migrate your apps to Azure AD. For additional resources to help guide you through app migration from AD FS to Azure AD, be sure to review the guidance below: