Code Monkey home page Code Monkey logo

identityserver4.wsfederation's Introduction

IdentityServer4.WsFederation

Sample for implementing WS-Federation IdP support for IdentityServer4

Overview

IdentityServer4 is designed to be extensible with custom protocol endpoints. This repo shows a simple implementation of WS-Federation IdP services. This is useful for connecting SharePoint or older ASP.NET relying parties to IdentityServer.

This is not supposed to be a generic WS-Federation implementation, but is rather a sample that you can use as a starting point to build your own WS-Federation support (or even for inspiration for integrating other custom protocols, which are not natively supported by IdentityServer4).

The following is a brief description of some technical points of interest. Feel free to amend this document if more details are needed.

.NET Support

The underlying WS-Federation classes used in this repo are only part of the "desktop" .NET Framework and are not included in .NET Core.

WS-Federation endpoint

The WS-Federation endpoint (metadata, sign-in and out) is implemented via an MVC controller (~/wsfederation). This controller handles the WS-Federation protocol requests and redirects the user to the login page if needed.

The login page will then use the normal return URL mechanism to redirect back to the WS-Federation endpoint to create the protocol response.

Response generation

The SignInResponseGenerator class does the heavy lifting of creating the contents of the WS-Federation response:

  • it calls the IdentityServer profile service to retrieve the configured claims for the relying party
  • it tries to map the standard claim types to WS-* style claim types
  • it creates the SAML 1.1/2.0 token
  • it creates the RSTR (request security token response)

The outcome of these operations is a SignInResponseMessage object which then gets turned into a WS-Federation response and sent back to the relying party.

Configuration

For most parts, the WS-Federation endpoint can use the standard IdentityServer4 client configuration for relying parties. But there are also options available for setting WS-Federation specific options.

Defaults

You can configure global defaults in the WsFederationOptions class, e.g.:

  • default token type (SAML 1.1 or SAML 2.0)
  • default hashing and digest algorithms
  • default SAML name identifier format
  • default mappings from "short" claim types to WS-* claim types

Relying party configuration

The following client settings are used by the WS-Federation endpoint:

public static IEnumerable<Client> GetClients()
{
    return new[]
    {
        new Client
        {
            // realm identifier
            ClientId = "urn:owinrp",
            
            // must be set to WS-Federation
            ProtocolType = ProtocolTypes.WsFederation,

            // reply URL
            RedirectUris = { "http://localhost:10313/" },
            
            // signout cleanup url
            LogoutUri = "http://localhost:10313/home/signoutcleanup",
            
            // lifetime of SAML token
            IdentityTokenLifetime = 36000,

            // identity scopes - the associated claims will be used to call the profile service
            AllowedScopes = { "openid", "profile" }
        }
    };
}

WS-Federation specific relying party settings

If you want to deviate from the global defaults (e.g. set a different token type or claim mapping) for a specific relying party, you can define a RelyingParty object that uses the same realm name as the client ID used above.

This sample contains an in-memory relying party store that you can use to make these relying party specific settings available to the WS-Federation engine (using the AddInMemoryRelyingParty extension method). Otherwise, if you want to use your own store, you will need an implementation of IRelyingPartyStore.

Configuring IdentityServer

This repo contains an extension method for the IdentityServer builder object to register all the necessary services in DI, e.g.:

services.AddIdentityServer()
    .AddSigningCredential(cert)
    .AddInMemoryIdentityResources(Config.GetIdentityResources())
    .AddInMemoryApiResources(Config.GetApiResources())
    .AddInMemoryClients(Config.GetClients())
    .AddTestUsers(TestUsers.Users)
    .AddWsFederation()
    .AddInMemoryRelyingParties(Config.GetRelyingParties());

Connecting a relying party to the WS-Federation endpoint

Using Katana

Use the Katana WS-Federation middleware to point to the WS-Federation endpoint, e.g.:

public void Configuration(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = "Cookies"
    });

    app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions
    {
        MetadataAddress = "http://localhost:5000/wsfederation",
        Wtrealm = "urn:owinrp",

        SignInAsAuthenticationType = "Cookies"
    });
}

SharePoint

see https://www.scottbrady91.com/Identity-Server/IdentityServer-4-SharePoint-Integration-using-WS-Federation

identityserver4.wsfederation's People

Contributors

arashrohani avatar brockallen avatar leastprivilege avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

identityserver4.wsfederation's Issues

SAML 1.1 Token Comparison

Based on investigation with SharePoint integration, I can get authentication working with IdentityServer 3 but not IdentityServer 4.

The SAML 1.1 tokens they generate are slightly different, so take a look and see what you think. I don't think this is the root of the issue, but I'd appreciate your opinion.

SAML 1.1 Tokens.zip

SAML Token Lifetime

SharePoint relying parties are currently silently failing due to tokens expiring during their login process.

Tokens are currently set to the same lifetime as the identity token (defaults to 300 seconds). Previous token lifetime in IdentityServer 3 was 10 hours. I imagine there's a more sensible number in between these :p

Is it worth adding in a SAML token lifetime to the relying party model?

Incorrect parameter used when performing home realm selection

An issue which has caused me many problems, which I have recently solved, is that, on the netstandard2.0 branch, the wrong parameter is used when the relying party chooses the home realm.

The parameter being assigned to the IdP property is the wtrealm parameter, when it should be the Whr parameter. This is correct in the master branch, where it uses the HomeRealm property.

wfresh="0" support and a NuGet package

Hi,

I am curious what plans there are to have wfresh="0" support added and this repo made available through a NuGet package. This repo is currently not available as a NuGet package where IdentityServer3.WsFederation was made available as a NuGet package.

I did previously ask in #12 if wfresh="0" support could be added and this was added as a task, but that pr is now closed without wfresh="0" support, so I'm not sure if this task is still being tracked. @AlexejKowalew made a fork of the netstandard2.0 branch available as a NuGet package, but now that his PR is merged, I'm not sure what the plans are for that fork and Nuget package.

I'm also not sure if there are any remaining blocking issues on the netstandard2.0 branch in this repo. I'm happy to host IdentityServer on .NET framework instead of .NET Core, so if the net461 branch is more stable, I'm happy to see wfresh="0" support added to that branch first and made available as NuGet package.

Also happy to help out with adding wfresh="0" support, but not sure which branch or fork to start that will have a NuGet package soonest.

kind regards

Remco

Necessity of full .NET framework

Is it still true that this functionality has to rely on using the 'desktop' .NET framework? I would like to be able to use this in a .net core linux container.

Signout without wtrealm with IdentityServer as claims provider in ADFS 2016

Hi,

Missing support for PostLogoutRedirectUri was discussed here #9. The suggested solution to pass an id_token_hint from the WsfederationController with the wtrealm does not work when using IdentityServer as a claims provider in ADFS 2016. ADFS 2016 does not pass the wtrealm parameter to the claims provider on signout. I went back to my IdentityServer 3 claims provider in ADFS 2016 and this one handles the signout ok without the wtrealm parameter. Why does IdentityServer 4 require this? Is there another way to generate the id_token_hint? Perhaps with the suggested WsFederationSignoutRequestValidator? Will it be able to generate the id_token_hint without the wtrealm parameter?

Code for Relying Party store using a database

Hi,

I am currently using the WSFederation protocol with Identity Server 4. I am using EF migrations for configuration and operational data but I dont want to use AddInMemoryRelyingPartyStore method to add the Relying Parties. Could you add a sample code on how to use the same database (SQl Express) and migrate Relying Party store class and then using DBContext just like we did for configuration data.

Thanks
Paramdeep Singh

NameIdentifier claim added twice

I'm using IdentityServer4 + WS-Federation sample from this repo + ASP.NET Identity and getting error "InvalidOperationException: ID4139: No suitable Saml2NameIdentifier could be created for the SAML2:Subject because more than one Claim of type NameIdentifier was supplied." while login. Without ASP.NET Identity everything works as supposed (e.g. by using TestUserStore). I identified this as a bug in SignInResponseGenerator.cs -> CreateSubjectAsync-method where NameIdentifier is added twice.

First in here

var nameid = new Claim(ClaimTypes.NameIdentifier, result.User.GetSubjectId());  
nameid.Properties[ClaimProperties.SamlNameIdentifierFormat] = result.RelyingParty.SamlNameIdentifierFormat;
var outboundClaims = new List<Claim> { nameid };

And after that in foreach-loop

var outboundClaim = new Claim(result.RelyingParty.ClaimMapping[claim.Type], claim.Value);
if (outboundClaim.Type == ClaimTypes.NameIdentifier)
{
    outboundClaim.Properties[ClaimProperties.SamlNameIdentifierFormat] = result.RelyingParty.SamlNameIdentifierFormat;
}
outboundClaims.Add(outboundClaim);

I can fix this locally, but it's a good idea to fix your sample too.

BTW: Do you have any plans to make a WS-Federation nuget package (IdentityServer4 plugin) based on this sample?

Missing support for PostLogoutRedirectUri

As I understand it the redirect to connect/endsession in WsFederationController.ProcessSignOut() need parameters for id_token_hint and post_logout_redirect_uri to have IdentityServer4 make a final redirect to the client during logout.
I don't understand how to create/get the id_token for getting this to work, any suggestions?

Or, do I have to create and register a custom EndSessionRequestValidator for this to work?

Would using Microsofts WsFederation-Implementation make it less complex?

Hi,

I saw that you added Microsoft.AspNetCore.Authentication.WsFederation to the AspNetCoreWsFederation- project. Would adding this to the IdentityServer4.WsFederation-project make the implementation less complex or is your implementation still the easiest? I tried adding Microsofts WSFederation-middleware to the EF-Quickstart and logically get errors because of the bad subject-claim, probably others will follow. I now need to decide if I should try to get Microsofts WSFederation to work with IdentityServer4 or start from your solution - any hints would be greatly appreciated.

Thanks & best regards,
Compu

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.