The art of simplicity

While preparing our MFA rollout at ADFS level, we started making the switch from classic authorization rules to custom access control policies in ADFS. This post explains the difference and the rationale behind this switch. A tale of two mechanisms When you work with Active Directory Federation Services (ADFS), there are two ways to control what happens when a user tries to authenticate: authorization rules and access control policies . On the surface, they feel similar; both let you define conditions around user access. But under the hood, they represent two distinct generations of the same capability. Understanding the difference matters especially when implementing MFA, because the mechanism you choose affects flexibility, maintainability, and how cleanly your logic can scale. Authorization rules: the classic approach Authorization rules are the original ADFS mechanism, introduced back when claims-based identity was first baked into the platform. They use a proprietary la...

This week a colleague contacted me with an issue he encountered after upgrading to .NET 8.0. On the project involved we were using the WsFederation middleware to authenticate and interact with ADFS. However after upgrading to .NET 8 and the 8.x version of the Microsoft.AspNetCore.Authentication.WsFederation middleware the trouble began. Using this version resulted in a change in behavior as suddenly the middleware starts to expect a SAML 2.0 token instead of a SAML 1.1 token that is now issued by our ADFS server: XmlReadException: IDX30011: Unable to read XML. Expecting XmlReader to be at ns.element: 'urn:oasis:names:tc:SAML:2.0:assertion.Assertion', found: 'urn:oasis:names:tc:SAML:1.0:assertion.Assertion'. Although I found a post online that it would be technically possible to let ADFS return a SAML 2.0 token through WSTrust, this doesn’t fit in the passive federation scenario we had, so time to look at some alternative solutions. Attempt 1 – Reverting to an ...

It looked like most of the world has made the switch to Microsoft Entra(Azure Active Directory). However one of my clients is still using ADFS. Unfortunately there isn't much information left on how to get an OAuth flow up and running in ADFS. Most of the links I found point to documentation that no longer exists. So therefore this short blog series to show you end-to-end how to get an OAuth Client Credentials flow configured in ADFS. Part 1 - ADFS configuration Part 2 – Application configuration Part 3 – Debugging the flow Part 4 (this post) – Understanding and fixing returned error codes Last post we updated our configuration so we could see any errors returned and are able to debug the authentication flow. In the first 2 posts I showed you everything that was needed to get up and running. The reality was that it took some trial and error to get everything up and running. In this post I share all the errors I got along the way and how I fixed them. IDX10204: Unabl...

It looked like most of the world has made the switch to Microsoft Entra(Azure Active Directory). However one of my clients is still using ADFS. Unfortunately there isn't much information left on how to get an OAuth flow up and running in ADFS. Most of the links I found point to documentation that no longer exists. So therefore this short blog series to show you end-to-end how to get an OAuth Client Credentials flow configured in ADFS. Part 1 - ADFS configuration Part 2 – Application configuration Part 3 (this post) – Debugging the flow In the first 2 posts I showed you the happy path. So if you did everything exactly as I showed, you should end up with a working Client Credentials flow in ADFS. Unfortunately there are a lot of small details that matter, and if you make one mistake you’ll end with a wide range of possible errors. In today’s post, I focus on the preparation work to help us debug the process and better understand what is going on. Updating your OAuth Confi...

It looked like most of the world has made the switch to Microsoft Entra(Azure Active Directory). However one of my clients is still using ADFS. Unfortunately there isn't much information left on how to get an OAuth flow up and running in ADFS. Most of the links I found point to documentation that no longer exists. So therefore this short blog series to show you end-to-end how to get an OAuth Client Credentials flow configured in ADFS. Part 1 - ADFS configuration Part 2 (this post) – Application configuration After doing all the configuration work in ADFS, I’ll focus today on the necessary work that needs to be done on the application side. Configuring the API We’ll start by configuring the API part. First create a new ASP.NET Core API project dotnet new webapi --use-controllers -o ExampleApi Add the ‘ Microsoft.AspNetCore.Authentication.JwtBearer ’ package to your project: dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer Add the auth...

It looked like most of the world has made the switch to Microsoft Entra(Azure Active Directory). However one of my clients is still using ADFS. Unfortunately there isn't much information left on how to get an OAuth flow up and running in ADFS. Most of the links I found point to documentation that no longer exists. So therefore this short blog series to show you end-to-end how to get an OAuth Client Credentials flow configured in ADFS. In todays post, I focus on the ADFS configuration. To make it not unnecessary complex, I’ll show the steps using one of the simplest OAuth flows; the Client Credentials flow . OAuth Client Credentials flow The OAuth Client Credentials flow is an authentication method used primarily for machine-to-machine (M2M) communication. In this flow, an application (the "client") requests an access token directly from an OAuth 2.0 authorization server using its own credentials, without involving a user. This access token allows the client to acces...

At one of my clients we have multiple ADFS instances, one for testing purposes and one for production usage. The information on both servers is almost the same, only the endpoints for each relying party are different. Before we typically copied information from one server to another manually, typing over all the information. Of course this is a a cumbersome and error-prone process. I decided to simplify and automate this process with the help of some Powershell. The good news was that the hard work was already done for me, as Brad Held already created a script for exactly that purpose: PowerShell Gallery | Copy-RelyingPartyTrust 1.1 Here is how to use this script: Copy-RelyingPartyTrust.ps1 -sourceRPID testing:saml:com -path C:\Folder -filename SamlTest.json -import false As I found the script a little bit confusing I took the freedom to adapt the code and split it out in 2 separate scripts. Here is the export script: You can use this script like this: export.ps1 -rp...

ADFS has the concept of claim rules which allow you to enumerate, add, delete, and modify claims. This is useful when you want for example introduce extra claims (based on data in a database or AD) or transform incoming claims. I wrote about claim rules before but I want to give a heads up about some of the lessons I learned along the way. Lesson 1 - Claim rules can be configured at 2 levels There are 2 locations in ADFS where you can configure claim rules. The first one is at the level of the relying party: The second is at the level of the claims provider: If you don’t know what either is, a short explanation: In Active Directory Federation Services (ADFS), a claims provider is the entity that authenticates users and issues claims about them. This can be Active Directory but also another IP-STS. A relying party is an application or service that relies on the claims provided by the claims provider to make authorization decisions. Essentially, the claims provider verif...

Our ASP.NET Core applications typically use WS-Federation with ADFS as our Identity Provider. After configuring a new application(Relying Party) in ADFS the first authentication attempt failed with the following error message: Encountered error during federation passive request. A look at the event viewer gave us more details: Protocol Name: wsfed Relying Party: https://localhost/example/ Exception details: Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. ---> Microsoft.IdentityServer.Service.IssuancePipeline.CallerAuthorizationException: MSIS5007: The caller authorization failed for caller identity <domain>\<ADUser> for relying party trust https://localhost/example/ .    at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)    at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result) ...

After creating a new claims rule, our ADFS instance started to return the following error message: The new rule we created just pass an existing claim value: c:[Type == "urn:be:vlaanderen:acm:rrn"]    => issue(claim = c); To explain why this error happened I have to give some extra context. Our ADFS instance is federated with another Identity Provider STS(IP-STS) and is acting as a resource STS(R-STS). The communication between the IP-STS and the R-STS(our ADFS instance) is done through the SAML 2.0 protocol and the tokens returned are also in SAML 2.0 format. However the communication between the R-STS and the relying party(an ASP.NET Core application) is done through WS-Federation and the token format used there is SAML 1.1 . SAML tokens have URI (ClaimType) rules that will differ based on the version of the SAML token you intend to issue. AD FS 2.0 supports WS-Federation, WS-Trust, and SAML 2.0 protocols. WS-Federation protocol only supports SAML 1.1 tok...

ADFS has the concept of claim rules which allow you to enumerate, add, delete, and modify claims. This is useful when you want for example introduce extra claims (based on data in a database or AD) or transform incoming claims. Although the available documentation is already helpful, I still find it a challenge to write my own claim rules. So therefore this post… Claim rule components To start a claim rule consists of 2 parts, separated by the “=>” operator: An optional(!) condition An issuance statement So both these rules are correct: Rule #1: => issue(type = "https://test/role", value = "employee"); Rule #2: c:[type == "https://test/employee", value == "true"] => issue(type = "https://test/role", value = "employee") The first rule will always generate a new outgoing claim of type https://test/role . The second rule will only generate a new outgoing claim of type https://t...

Yesterday I worked in close collaboration with one of my clients to renew the certificates on their ADFS server. Of course this wouldn't be an interesting post if nothing went wrong and there was nothing to learn. Changing the certificate is quite easy. First upload the certificate to your ADFS instance through the ADFS Management UI: Open Server Manager Click on “Tools”. Select “AD FS Management” from the menu. Expand “Service” node and click on “Certificates”. Click on “Set Service Communication Certificate” on the right side. Now you can activate this certificate using the following command: Set-AdfsSslCertificate -Thumbprint {thumbprint} That’s the easy part. So where did we get into trouble? After changing the certificate, some of our .NET applications started to fail with the following error message: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the Issu...

I have an ASP.NET Core application that is using WSFederation as authentication protocol. The application authenticates through our internal ADFS server where a corresponding Relying Party is configured. When attempting to authenticate, the ASP.NET Core application returns the following error message: SecurityTokenException: No token validator was found for the given token. Here is the full error page: I had a look at the application configuration, but everything looked fine there: The issue turned out to be related to the Relying Party configuration in ADFS. I had enabled token encryption there but this is not supported by the WSFederation middleware in ASP.NET Core. Here is how to fix it: Go to your ADFS server Open ADFS Management Go to Relying Parties and click on the Relying Party you want to configure Go to the Encryption tab and click Remove to delete the existing certificate

One of my clients is using Microsoft ADFS as their Security Token Service. Through ADFS people can login either by using their e-id(Belgian passport) or through their internal domain account (using Windows authentication). After upgrading our ADFS server, we noticed that people were asked for their credentials and that their windows credentials were not passed automatically. This is of course quite annoying. We took a look at the ADFS settings and noticed that ‘mozilla/5.0’ was missing from the list of user agents: PS C:\Users\bawu> (Get-AdfsProperties).Wiasupporteduseragents MSAuthHost/1.0/In-Domain MSIE 6.0 MSIE 7.0 MSIE 8.0 MSIE 9.0 MSIE 10.0 Trident/7.0 MSIPC Windows Rights Management Client MS_WorkFoldersClient =~Windows\s*NT.*Edge To fix it we updated the list of supported agents: Set-ADFSProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain","MSIE 6.0", "MSIE 7.0", "M...

ADFS is great as long as it works. But when you get into trouble, all the help you can find is welcome… While investigating an ADFS issue, I found the AD FS Help website : This website combines a list of of both online and offline tools that can help you configure, customize and troubleshoot your ADFS instance.

In one my ASP.NET Core applications we are (still) using WSFederation as the authentication protocol. While implementing the signout functionality I noticed that I correctly was signout at ADFS level but that ADFS didn’t return me back to my application afterwards. This is handled by the wreply parameter and this parameter was correctly send to ADFS. Here is my logout code: After some trial and error I could pinpoint the issue to the following situation; when the reply URL was a subpath of the configured WSFederation endpoint it worked and I got correctly redirected. For example: The ADFS WSFederation endpoint for my Relying Party was configured to use https://localhost/example/federationresult/ If I used https://localhost/example/logoutsuccess/ as reply URL nothing happened and I stayed on the ADFS logout page If I used https://localhost/example/federationresult/logoutsuccess/ as reply URL I am correctly redirected back to my application I guess it makes sen...

After adding a claims provider trust in ADFS, we got the following error message when trying to use the configured 3th party IP-STS. The audience restriction was not valid because the specified audience identifier is not present in the acceptable identifiers list of this Federation Service. User Action See the exception details for the audience identifier that failed validation. If the audience identifier identifies this Federation Service, add the audience identifier to the acceptable identifiers list by using Windows PowerShell for AD FS.  Note that the audience identifier is used to verify whether the token was sent to this Federation Service. If you think that the audience identifier does not identify your Federation Service, adding it to the acceptable identifiers list may open a security vulnerability in your system. Exception details: Microsoft.IdentityServer.AuthenticationFailedException: ID1038: The AudienceRestrictionCondition was not valid because ...

While trying to get WSFederation working inside an ASP.NET Core application, I got the following error message: SecurityTokenInvalidAudienceException: IDX10214: Audience validation failed. Audiences: '[PII is hidden]'. Did not match: validationParameters.ValidAudience: '[PII is hidden]' or validationParameters.ValidAudiences: '[PII is hidden]'. Hiding the PII seems a good idea from a security perspective but makes it hard to debug this problem. To make the PII visible, you can add the following line of code:

OAuth 2.0 supports several different grants . By grants we mean ways of retrieving an Access Token. Unfortunately it can be quite a challenge to find out which grant should be used in which situation. The guys from Auth0 created the following diagram to help you arrive at the correct grant type: