Connecting the Rock Solid Knowledge WS-Federation stack on identityserver4 to ADFS 4.0

Rory Braybrook
Dec 5, 2018 · 5 min read

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).

: 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:

https://localhost:44309/wsfed

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 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!

The new control plane

“Identity is the new control plane”. Articles around Microsoft Identity, Auth0 and identityserver. Click the “Archive” link at the bottom for more posts.

Thanks to Scott Brady.

Rory Braybrook

Written by

NZ Microsoft Identity dude. Azure AD/ADFS. Plus Auth0. North Shore .NET User Group Admin. Ignite - http://bit.ly/2D05Uh7 YouTube - http://bit.ly/2lzBqXQ

The new control plane

“Identity is the new control plane”. Articles around Microsoft Identity, Auth0 and identityserver. Click the “Archive” link at the bottom for more posts.