ellenfieldn / identityserver4.wsfederation

Full .Net Core implementation of WsFederation for IdentityServer4

IdentityServer4.WsFederation

Plugin for IdentityServer4 that enables IdentityServer to function as a Ws-Federation Identity Provider.

Getting Started

The easiest way to get started is to:

1. Clone the IdentityServer4.Quickstart project of your choice (unless you plan to build the UI from scratch)
2. Install the IdentityServer4.Contrib.WsFederation package.
3. Configure Startup.cs as below

Also, see the Samples folders for a working server (src/SampleServer) and client (src/SampleClient).

The code

Do the following in Startup.cs to use this plugin with Asp.net Core. If you don't use MVC, obviously take that out.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    // If you don't manually specify the digest and signature algorithms, it'll fail.
    var certificate = new X509Certificate2("IdentityServer4.WsFederation.Testing.pfx", "pw");
    var signingCredentials = new SigningCredentials(new X509SecurityKey(certificate), SecurityAlgorithms.RsaSha256Signature, SecurityAlgorithms.Sha256Digest);

    var builder = services.AddIdentityServer(options => 
    {
        options.IssuerUri = "urn:idsrv4:wsfed:server:sample";
    })
    .AddSigningCredential(signingCredentials) // Must use this overload.
    .AddTestUsers(TestUsers.Users)
    .AddInMemoryClients(Clients.TestClients)
    .AddInMemoryApiResources(new List<ApiResource>())
    .AddWsFederation();
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    //OtherStuff
    app.UseIdentityServer();
    // app.UseMvc.....
}

Supported Functionality

Right now, this library is in alpha. Consequently, only a subset of the WsFederation standard is supported. It's also likely that some features of IdentityServer aren't well integrated yet.

Supported Workflows

• Signin
• Metadata
• Signout

Supported Parameters

• wa
• wreply
• wctx
• wfresh

Supported Outputs

• wa
• wresult
• wctx

Something Vaguely Resembling a Roadmap

I plan to do this stuff.

Near-term features

These things are pretty much goals for the mid-term.

• Supporting the rest of the request parameters
• Better input validation.
• Events.

Long-term features

These will mostly correspond to the parts of WsFederation that were not mentioned above.

• Rst as an input parameter.
• Pointers to the incoming rst or outgoing rstr.
• Encryption?
• Different token types - SAML 1.1 vs SAML 2.0

identityserver4.wsfederation's Issues

Add basic functional tests

I'd like to create functional tests that exercise the workflows from the perspective of the user without having to deal with deployment (yet). For now, we'll just POC it and see how it goes.

Implement logging

Need to implement logging in the standard asp.net core way.

Release 0.1.1

prepare and publish v2.0 nugets

Generate nuget package for alpha build 0.1

Version 0.1 will likely just have support for the signin workflow

Add ability to customize claims

Currently, there's no good way to customize the claims that are output in a token.

Ideally, the relying party should be able to specify default claims as well as restrict which claims can be issued.

Add WsFederation Signout Workflow - Cleanup phase

cleanup code

Some stuff got a little messy with the signout support

Support SAML 1.1 and SAML 2.0 tokens

Currently SAML 2.0 tokens are supported.

For deserialization, support a list of supported token types.
For serialization, support a default token type option.

WsFederation Signout workflow

Bad DateTime format for the Token Lifetime

Both, Created and Expires XML elements have wrong date format according to the rest of the elements in the Assertion:

<Lifetime>
    <Created xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">7/4/2019 9:26:14 AM</Created>
    <Expires xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">7/4/2019 9:31:14 AM</Expires>
</Lifetime>

Add support for wfresh

Handle wfresh

• wfresh is not included - Used cached authentication as usual
• wfresh is included and set to n where n >0 - Used cached authentication if it is less than n minutes old
• wfresh is included and set to 0 - Force reauthentication

Come up with signout wreply strategy for user authenticated with multiple clients

Add WsFederationOptions and the ability to enable/disable WsFederationEndpoints

It's about time to add WsFederationOptions. For now, we'll start by making it possible to enable and disable the various WsFederationEndpoints:

• Metadata
• Signin
• Singout

Fill in functional tests

Functional testing coverage is pretty light. Would like to fill in a bit more

support default wreply

If a wreply is not specified in the original signin message, use a default one.

Add unit tests.

What's the status of this project?

What is the current status of this project? I see that identityserver guys archived the project and are now selling it instead of posting it on GitHub which lead me here. Is this project active and can you use it?

NameID Missing in SAML 2 token

Name Identifier is missing in the WS Federation token, here is the XML tag:

      <saml:Subject>
        <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
      </saml:Subject>

a very fast fix:

        public async Task<string> GenerateSerializedRstr(ValidatedWsFederationSigninRequest request)
        {
            var principal = request.Subject.Identity as ClaimsIdentity;
            if (principal.FindFirst(ClaimTypes.NameIdentifier) == null) {
                principal.AddClaim(new Claim(ClaimTypes.NameIdentifier, principal.Name));
            }
          .......

I may create a PR with the code change

update documentation for signout

Add support for events

Add support for IdentityServer4 events.

add copyright headers to all files

switch to using Microsoft.AspNetCore.App

Currently we use the .All package.

Update readme to reflect the publication of the nuget

Move extension methods to the microsoft dependency injection namespace

This makes the extension methods more discoverable. Otherwise, with certain IDEs, uses will have to find our extension method namespace before being able to see the extension methods.

I see it done in a lot of asp.net core middleware, and I guess this is the reason.