-
Notifications
You must be signed in to change notification settings - Fork 360
ADFS support
There are two cases:
- MSAL.NET talks to Azure Active Directory, which itself is federated with other identity providers (IdPs). In the case we are interested in the federation happens through ADFS.
- MSAL.NET talks directly to an ADFS authority. This can only happen if ADFS is OIDC compliant (from ADFS 2019). One of the scenarios this highlights is Azure Stack support
MSAL.NET supports talking to Azure AD, which itself signs-in managed users (users managed in Azure AD), or federated users (users managed by another identity provider, which, in the case we are interested is federated through ADFS). MSAL.NET does not know about the fact that users are federated. As far as it’s concerned, it talks to Azure AD.
The authority you'll use in the case is the usual authority (common, or organizations, or tenanted)
When you call AcquireTokenAsync()
, in term of user experience:
- the user enter their upn (or the account or loginHint is provided part of the call to AcquireTokenAsync)
- Azure AD displays briefly "Taking you to your organization's page",
- and then redirects the user is to the sign-in page of the identity provider (usually customized with the logo of the organization)
Supported ADFS versions in this federated scenario are ADFS v2 , ADFS v3 (Windows Server 2012 R2) and ADFS v4 (ADFS 2016)
TODO
In that case the authority you'll want to use to build your application is something like https://somesite.contoso.com/adfs/
MSAL.NET will support ADFS 2019 (PR is ADFS Compatibility with MSAL #834), which is/will be Open ID Connect compliant after a service pack is applied to Windows Server.
However MSAL.NET does not support, and will not support, a direct connection to ADFS 2016 or ADFS v2 (which are not OIDC compliant). If you need to support scenarios needing a direct connection to ADFS 2016, please use the latest version of ADAL.
- Home
- Why use MSAL.NET
- Is MSAL.NET right for me
- Scenarios
- Register your app with AAD
- Client applications
- Acquiring tokens
- MSAL samples
- Known Issues
- AcquireTokenInteractive
- WAM - the Windows broker
- .NET Core
- Maui Docs
- Custom Browser
- Applying an AAD B2C policy
- Integrated Windows Authentication for domain or AAD joined machines
- Username / Password
- Device Code Flow for devices without a Web browser
- ADFS support
- Acquiring a token for the app
- Acquiring a token on behalf of a user in Web APIs
- Acquiring a token by authorization code in Web Apps
- High Availability
- Token cache serialization
- Logging
- Exceptions in MSAL
- Provide your own Httpclient and proxy
- Extensibility Points
- Clearing the cache
- Client Credentials Multi-Tenant guidance
- Performance perspectives
- Differences between ADAL.NET and MSAL.NET Apps
- PowerShell support
- Testing apps that use MSAL
- Experimental Features
- Proof of Possession (PoP) tokens
- Using in Azure functions
- Extract info from WWW-Authenticate headers
- SPA Authorization Code