Connecting the Rock Solid Knowledge WS-Federation stack on identityserver4 to ADFS 4.0
Rock Solid Knowledge (RSK) already have a SAML 2.0 plug-in for idsrv4 and now they have bought out support for WS-Federation. Currently, this is in beta.
Note that the RSK stack is only for Identity Provider (IDP) support. There is currently no support in the RSK stack to run as a Relying Party (RP).
Aside: It’s worth noting that WS-Fed RP support is built into ASP.NET Core and hence usable from IdentityServer.
The WS-Fed RSK article gives a good overview.
There is a NuGet package.
There is also a RSK GitHub sample that I used for this post.
ADFS needs https to run so in the sample, set SSL for the IDP
You need to update the RP URL:
//options.MetadataAddress = “http://localhost:5000/wsfed";
options.MetadataAddress = “https://localhost:44309/wsfed";
Use whatever SSL port is configured for your Visual Studio instance.
The RSK WS-Fed stack is only on the IDP side in the sample — the RP in the sample uses the existing .NET Core WS-Fed library.
The IDP metadata is at:
For this post, ADFS needs to be the RP i.e. idsrv4 needs to be CP.
The flow is then:
WS-Fed Client → ADFS → (via RSK WS-Fed) → idsrv4
In other words, ADFS acts as an IDP for the flow on the left and as a RP for the flow on the right.
I suggest you test the sample implementation to make sure it’s all configured correctly before you add ADFS into the mix. The RP then talks to the IDP. You can authenticate with the in-memory users viz. “alice / alice” or “bob / bob”.
I found that the RP sample that uses .NET Core WS-Fed support doesn’t work against ADFS. ADFS complains about malformed messages.
So I ran up a WS-Fed client using the on-premises authentication option in VS.
The sample uses a self-signed certificate. This causes problems with ADFS because ADFS checks the certificate revocation list (CRL). Obviously, there isn’t one for a self-signed certificate.
The error is:
An error occurred during an attempt to build the certificate chain for the claims provider trust ‘https://localhost:44309' certificate identified by thumbprint ‘6B7ACC520305BFDB4F7252DAEB2177CC091FAAE1’. Possible causes are that the certificate has been revoked, the certificate chain could not be verified as specified by the claims provider trust’s signing certificate revocation settings or certificate is not within its validity period.
To get around this, run this PowerShell.
Set-AdfsClaimsProviderTrust -Targetname “idsrv4 wsfed” -SigningCertificateRevocationCheck None
Note that the idsrv4 IDP settings are:
and the client settings are:
The Client code in the IDP Startup.cs is:
private static readonly Client RelyingParty = new Client
{
ClientId = “http://my-adfs/adfs/services/trust",
AllowedScopes = { “openid”, “profile” },
RedirectUris = { “my-adfs/adfs/ls/" },
ProtocolType = IdentityServerConstants.ProtocolTypes.WsFederation
};
In the ADFS wizard , we add a claims provider (CP) via the option — “Add Claims Provider Trust”
Use the “Import data” option to import the idsrv4 metadata.
The CP settings are then:
Ad the client via the ADFS wizard — “Add Relying Party Trust”.
I configured it manually.
ADFS is essentially being used in pass-through mode so we need to pass the idsrv4 claims through both the CP and the RP.
You can do this on both the CP and the RP by using a custom claim:
where the claim rule is:
c:[]
=> issue(claim = c);
If you don’t do this, you will get the ADFS error:
System.ArgumentException: A SamlAssertion requires at least one statement. Ensure that you have added at least one SamlStatement to the SamlAssertion you are creating.
Note that for debugging, you can also use the “SAML Tracer” plugin for Firefox” (it has WS-Fed support 😃).
So let’s try it.
Running the client takes us to the the ADFS Home Realm Discovery screen.
We pick the “idsrv4 wsfed” option.
This takes us to the idsrv4 login screen:
You can authenticate with the in-memory users viz. “alice / alice” or “bob / bob”.
Success!
All good!
