Announcing WS-Federation Support for IdentityServer4 and .NET Core

•
Date Posted: 22 December 2018; •
Author: Scott Brady; •
Estimated Reading Time: 5 minute read

We are pleased to announce the open BETA of the IdentityServer4 WS-Fed component, allowing IdentityServer to act as an Identity Provider (IdP) using WS-Federation...

Rock Solid Knowledge are pleased to announce the open beta of the IdentityServer4 WS-Federation component. This component allows IdentityServer to act as an Identity Provider (IdP) using WS-Federation, bringing cross-protocol single sign-on and allowing you to use IdentityServer to log into your legacy applications.

This component builds upon the popular WS-Federation proof of concept for IdentityServer, bringing .NET Core compatibility, and commercial support.

Feel free to reach out to [email protected] to give feedback or request features. We’re still working on the full feature set and pricing, with the beta ending in January.

Setup To get started with the IdentityServer4 WS-Federation component, you’ll first need to install the nuget library:

install-package Rsk.IdentityServer4.WsFederation

After installing the component, you can then update your call to AddIdentityServer in the ConfigureServices method with the following:

services.AddIdentityServer()
    // the rest of registrations (clients, resources, users, etc)
    .AddSigningCredential(new X509Certificate2(/*your cert*/))
    .AddWsFederationPlugin()
    .AddInMemoryRelyingParties(new List());

Here we have AddWsFederationPlugin bringing in the required dependences. In the future, this registration will require a license key.

With AddInMemoryRelyingParties you are bringing in a separate store for relying party configuration data. This is similar to the approach in our SAML component, however relying party configuration entries are optional for now. More on this later.

Then, in your Configure method, you can update our call to UseIdentityServer with the following:

app.UseIdentityServer()
   .UseIdentityServerWsFederationPlugin();

This allows your IdentityServer to start handling calls to the WS-Federation endpoints.

WS-Federation Identity Provider Metadata

You can now access the metadata for our WS-Federation identity provider. By default, this is available on the route /wsfed. This metadata document can be loaded in by relying parties so that they can automatically configure themselves to use your identity provider.

Adding a WS-Federation Relying Party

To configure a WS-Federation relying party, you need to create a client record within IdentityServer for them, that looks something like:

var relyingParty = new Client {
    ClientId = "rp1",
    AllowedScopes = {"openid", "profile"},
    RedirectUris = {"http://localhost:5001/signin-wsfed"},
    ProtocolType = IdentityServerConstants.ProtocolTypes.WsFederation
};

This uses the usual Client entity, specifying the client ID as the expected entity ID of the relying party. What claims the relying party will receive is again controlled by identity scopes, with the claim types then being mapped by either the defaults in the WsFederationOptions or the RelyingParty configuration you’ll see shortly.

The protocol type must be wsfed, and the RedirectUris must contain the incoming wreply value.

To override default settings within the WsFederationOptions for an individual relying party, you can create a RelyingParty record alongside the client one. This entity must have a Realm that matches the ClientId on the client record.

var relyingPartyOverrides = new RelyingParty {
    Realm = "rp1",
    TokenType = WsFederationConstants.TokenTypes.Saml11TokenProfile11,
    ClaimMapping = new Dictionary{{JwtClaimTypes.Name, ClaimTypes.Name}}
};

Get in Touch

If you’re looking to solve a particular use case with our WS-Federation component or have any questions, then get in touch at [email protected].

Scott Brady

•
Job Role: Security Consultant