identityserver / identityserver3.wsfederation Goto Github PK

If I install the package from Nuget the DI Container gets setup as it should, and every plugin's dependency is registered.

But If I:

1. Download the source from Github
2. Build the assembly
3. Reference the Thinktecture.IdentityServer.WsFederation.dll for IdentityServer.

It causes an DI exception for the WsFederationController:

<Error>
<Message>An error has occurred.</Message>
<ExceptionMessage>
An error occurred when trying to create a controller of type 'WsFederationController'. Make sure that the controller has a parameterless public constructor.
</ExceptionMessage>
<ExceptionType>System.InvalidOperationException</ExceptionType>
<StackTrace>
at System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType) at System.Web.Http.Controllers.HttpControllerDescriptor.CreateController(HttpRequestMessage request) at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()
</StackTrace>
<InnerException>
<Message>An error has occurred.</Message>
<ExceptionMessage>
Type 'Thinktecture.IdentityServer.WsFederation.WsFederationController' does not have a default constructor
</ExceptionMessage>
<ExceptionType>System.ArgumentException</ExceptionType>
<StackTrace>
at System.Linq.Expressions.Expression.New(Type type) at System.Web.Http.Dispatcher.DefaultHttpControllerActivator.GetInstanceOrActivator(HttpRequestMessage request, Type controllerType, Func`1& activator) at System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType)
</StackTrace>
</InnerException>
</Error>

If more details needed please ask.

If for example IdSrv3 using WsFed was deployed into a web farm environment, which repositories require or would be highly recommended for shared state/storage instead of just in-memory stores?

(It seems there are quite a few OIDC specific stores for different things but I would like to focus specifically on WsFed)

When Identity Server is deployed behind a load balancer with SSL termination at the load balancer, one can use the IdentityServerOptions.PublicOrigin to control the URLs that are generated by Identity Server and make sure they look like the load balancer's endpoint.

Say the load balancer endpoint is https://my-public-id-srv and the nodes listen on http://node1:8080 and http://node2:8080. Notice that load balancer requires SSL while the nodes do not.

For this setup one sets a couple of properties in the IdentityServerOptions object:

IdentityServerOptions.PublicOrigin = "https://my-public-id-srv"
IdentityServerOptions.RequireSsl = False

There is an issue with the WSFederationController. In this setup, the Controller is generating a return URL with http instead of https.

Rather than getting the RequestUri like this:

string requestUri = Request.RequestUri.AbsoluteUri

Something like this should be used to honor the PublicOrigin property:

string identityServerHost = Request.GetOwinContext().Environment.GetIdentityServerHost();
string pathAndQuery = Request.RequestUri.PathAndQuery;
string requestUri = identityServerHost + pathAndQuery;

Regards,
-Santiago

PS: Yesterday opened a similar issue in the Google+ provider. (TerribleDev/OwinOAuthProviders#57)

It would be helpful if we could use e.g. Wreply provided by a client instead of getting it from relaying parties configuration. There are cases where the same application is installed into multiple servers and thus the reply address might be different for each of them (while other options remain the same). By using client provided reply address, we need to configure only one relaying party for all instances of the application.

Hi!

We want to filter/alter claims sent to relying parties, depending on the user and relying party. Currently, we do it in a custom SignInResponseGenerator implementation (inheriting SignInResponseGenerator), in CreateSubjectAsync(SignInValidationResult).

protected override async Task<ClaimsIdentity> CreateSubjectAsync(SignInValidationResult validationResult)
{
    var subject = await base.CreateSubjectAsync(validationResult);
    return new ClaimsIdentity(
        await TransformClaimsAsync(validationResult, subject),
        subject.AuthenticationType, 
        subject.NameClaimType,
        subject.RoleClaimType);
}

private async Task<IEnumerable<Claim>> TransformClaimsAsync(SignInValidationResult validationResult, ClaimsIdentity subject)
{
    [...]
}

Is there a better way? The obvious issue with this solution, is that the CreateSubjectAsync(SignInValidationResult) method is a private non-virtual method, and to be able to do the stuff above we have to keep a fork where the method signature is changed to protected virtual instead.

If this use case seems relevant to you, one option would of course be to change the signature of the method in this repo.

I'll happily create PRs, provide more detailed explanations and such if in any way needed. I'm also available in the gitter channel.

Looking back in the IdentityServer2 code there used to be a way to expose the offered claims in the wsfed/metadata document. This was done through implementing a custom ClaimsRepository and overriding GetSupportedClaimTypes()

This customization of the metadata document no longer seems possible in IdentityServer3. Are there plans to add this back in? If not I'll have to port the project I am working back to IdentityServer2 and that seems like a step in the wrong direction.

For testing purposes, would it be possible to change the access on the CreateSubjectAsync method in SignInResponseGenerator from private to protected? (https://github.com/IdentityServer/IdentityServer3.WsFederation/blob/master/source/WsFederationPlugin/ResponseHandling/SignInResponseGenerator.cs#L100)

Then, I could easily call this method in a test in order to test the entire claims handling in situ.

Hi,

If you want to restrict user access for some clients, i.e. only allow authorize or token requests for some users to certain clients, you can use the ICustomRequestValidator for non-WS-Federation requests (it gives you both subject and client, which is enough to make such a decision).

But the WsFederation plugin seems to lack such extension points. While replacing SignInValidator would be enough (with subject and realm, there is enough information to make a decision), that seems to be impossible to do from the outside, i.e. without forking?

Would it make sense to add an optional extension point like ICustomSignInValidator, or something similar? That would be very helpful for my usage scenario. Or at least make the SignInValidator overridable?

Thank you for this immensely useful project!

I have regular authentication working nicely, but I'd like to build out a slightly special journey where folks can automatically sign in as a particular user, "guestX" or "guestY" for example.

The best way seems to be to get parameter(s) into a custom UserService where an override of PreAuthenticateAsync(SignInMessage) could then decide whether to return an AuthenticationResult.

I have tweaked the existing code in WsFederationController to simply add a Login Hint just before the cookie gets written but was wondering if something more out of the box could be dynamically mapped from SignInRequestMessage(WsFed params) to the SignInMessage.

To summarise; I am hoping to put values into AuthenticationProperties at the point of initiating the sign in (on the RP side) which can then be evaluated by the UserService (IdSrv) which then may automatically sign the user in.

Anyone have thoughts on this?

The fix for #27 changed a line from .AbsoluteUri to .ToString(). The ToString() method for Uri does a multi-level unescape on the query string which essentially corrupts the Uri.

As an example, WIF redirects embed escaped values in a query string parameter to read on return, .ToString() unescapes recursively into plain text, and terminates the string when it sees a "bad" query string (extra =).

We haven't noticed any issues with changing it back to AbsoluteUri, and #27 still seems to be fixed.

I am upgrading IdSrv3 from 1.6.2 to 2.0.1. After authentication, when issuing the response at the wsfed endpoint in IdSrv, it throws this exception:

"Message":"An error has occurred.","ExceptionMessage":"ID4216: The ClaimType 'updated_at' must be of format 'namespace'/'name'.\r\nParameter name: claimType","ExceptionType":"System.ArgumentException","StackTrace":"   at System.IdentityModel.Tokens.SamlSecurityTokenHandler.CreateAttribute(Claim claim, SecurityTokenDescriptor tokenDescriptor)\r\n   at System.IdentityModel.Tokens.SamlSecurityTokenHandler.CreateAttributeStatement(SamlSubject samlSubject, ClaimsIdentity subject, SecurityTokenDescriptor tokenDescriptor)\r\n   at System.IdentityModel.Tokens.SamlSecurityTokenHandler.CreateStatements(SecurityTokenDescriptor tokenDescriptor)\r\n   at System.IdentityModel.Tokens.SamlSecurityTokenHandler.CreateToken(SecurityTokenDescriptor tokenDescriptor)\r\n   at System.IdentityModel.Tokens.SecurityTokenHandlerCollection.CreateToken(SecurityTokenDescriptor tokenDescriptor)\r\n   at IdentityServer3.WsFederation.ResponseHandling.SignInResponseGenerator.CreateSecurityToken(SignInValidationResult validationResult, ClaimsIdentity outgoingSubject) in c:\\ballen\\github\\identity\\IdSrv3\\IdentityServer3.WsFederation\\source\\WsFederationPlugin\\ResponseHandling\\SignInResponseGenerator.cs:line 186\r\n   at IdentityServer3.WsFederation.ResponseHandling.SignInResponseGenerator.<GenerateResponseAsync>d__1.MoveNext() in c:\\ballen\\github\\identity\\IdSrv3\\IdentityServer3.WsFederation\\source\\WsFederationPlugin\\ResponseHandling\\SignInResponseGenerator.cs:line 60\r\n--- End of stack trace from previous location where exception was thrown --

The 'updated_at' claim of the user is not in the 'namespace/name' format stated by the error message, rather it is a 10 digit number. I found this inspecting the claims returned by UserService.GetProfileDataAsync(ProfileDataRequestContext). What can be the cause of this?

When IssuerUri is not set, metadata and token generation fail with exception: "ID3203: An error occurred while writing the metadata document. Required parameter 'entityID' is not set."

Given the changes in Issuer config in IdSvr, this plugin did not react to those changes.

For metadata and creating security tokens. See: IdentityServer/IdentityServer3#2432

I apologize beforehand if this is the wrong place to post, but I'm trying to find more information on the setup of IdentityServer with ADFS v3.

Thanks

Hello guys,

Starting with this post http://www.wictorwilen.se/using-sharepoint-2013-with-thinktecture-identityserver-2 I wanna implement the same setup but using IS3 and WSFederation. Is this possible ? Can I use IS3 with WS-Federation to generate SAML1.1 tokens ?

If yes, how can I get the signinurl and Federation metadata xml ?

I have IS3 running, now I need a bit of guidance to connect SharePoint 2013 with IS3.

Thank you,

Ovidiu

The procedure of signing out of all RP's is achieved via performing a HTTP GET request through an iframe element:

"<iframe style=\"visibility: hidden; width: 1px; height: 1px\" src=\"{0}?wa=wsignoutcleanup1.0\"></iframe>";

There is an issue with this implementation if using HTTPS protocol on Idsrv and HTTP on RP's:

Mixed Content: The page at 'https://auth.domain.com/' was loaded over HTTPS, but requested an insecure resource 'http://client.com/'. This request has been blocked; the content must be served over HTTPS.

Explaination: https://developer.mozilla.org/en-US/docs/Security/MixedContent

Question: Was the iframe an intentional choice for preventing Mixed HTTPx requests.
Why not using an image instead ?
<img style=\"visibility: hidden; width: 1px; height: 1px\" src=\"{0}?wa=wsignoutcleanup1.0\">

I have cases where the POST of a form can cause an authorize redirect back to the Id Server to re-validate the token or ask the user to log in again, which is generally good except that the return url is not applicable for a GET request

-- Is there a good approach / pattern that can be applied to handle these cases?

Context:

RP apps which have been migrated from their own Forms Auth to now use IdSrv + WsFed.

It is reasonable to assume that folks may spend quite some time on a page before actually submitting the form.

This app is Asp.Net MVC though answers can be less specific

I also realise this is not strictly a WsFed problem but rather a question on how best to put it into practice with existing applications.

Persistence layer for relying parties configuration that uses EntityFramework.

Note: I wasn't sure if this issue belong here or in Thinktecture.IdentityServer.v3.EntityFramework.

Multiple and wildcard replyURLs for Relying Parties using WS-Fed

We currently use ADFS 3.0 as a «protocol Gateway» to authenticate SharePoint 2013 against our SAML2-based Identity Provider (Shibboleth). We have some problems with this constellation, because ADFS does not have a user store implemented and therefore each authentication request will pass the whole chain (SharePoint  ADFS  Shibboleth and backwards). For that reason we are investigating if we can replace the ADFS Server with a solution based on IdentityServer3 with the WS-Federation plugin together with Kentor Authentication Services (https://github.com/KentorIT/authservices). The first steps with Identity Server in our POC environment are very motivating Most of the stuff works very well but two issues are still to be addressed:

1. We use SharePoint Add-Ins. The way Add-Ins in SharePoint are implemented is that each app will get a unique random GUID URL based on the following schema: https://apps-GUID.myappdomain.com. (ex. https://apps-bd5b8584-fd5f-49fd-96b2-64b60927924c.myappdomain.com). In ADFS 3.0 it is possible to register a wildcard endpoint for the Add-In Domain like https://*.myappdomain.com.

2. On the other side SharePoint as the Relying Party needs to be configured that the WReply Parameter will be sent, so that the Identity Server knows, where the request need to be redirected. It is possible to register each app URL individually as its own relying Party, but our aim is that each power user can add Add-Ins by himself and then this is no longer working. This lead us to the second point. We need to have one Replying Party with multiple Endpoints (ReplyUrls) registered in Identity Server. This is needed so that the SharePoint Add-Ins are working and also because everything is covered in one realm it helps us for the token lifetime if we switch between the different URLs (applications).

Thank you very much for your help in advance.

Cheers, Joël

HI
I'm using Identity Server along with WsFederationPlugin to provide a Identity Server for three groups of users from two separate systems / dependent parties. Preferably I will show a separate login screen based on which rely party and user login request comes from, but if this is impossible, I will show a seperate login sceens based on the relying party. And so have a selection screen for the user to trust the party with two user groups.

Any help will be appreciated, thanks in advance!

Hi

I setup my idsrv with wsfed plugin, and everything works if I configure my relying parties to point at idsrv wsfed endpoint directly, but it fails if I have a azure ACS sit in the middle, basically i want following infrastructure:

RP ===> ACS ===> idsrv3

what happen is the idsrv receives request from ACS with ws-fed protocol and generates wsfed request message successfully, then it detects the end user hasn't been authenticated, which then it generates a signin message cookie so that the end user can sign in from login page.

The problem is that the signin message cookie doesn't get render out to browser, I debug through the whole pipeline, and found that it is because the signin cookie added to the OwinContext gets removed later on during the pipeline.

Further more, I also notice that the reason why though ACS doesn't work is because the wsfed request sent from ACS has encrypted wctx parameter as belowed, and if I change it to a dummy value , the signinmessage cookie wont be removed.

because lack of signin message cookie, i got an error on login page:

"There is an error determining which application you are signing into. Return to the application and try again."

Does anyone know why please?

Ming

Hello,

we are using IdentityServer3 with the WS-Federation Plugin as a Claims Provider Trust for AD FS, AD FS acts as the SAML2 IDP for a Shibboleth-SP. Local login with username and password works fine. We've been trying to add an external authentication via AusweisApp2/nPa, but the resulting SAML2 delivered to the Shibboleth-SP is missing an AuthnStatement element and creating a Shibboleth session fails.

After some research I think the reason is that the necessary claims are only added in the SignInResponseGenerator if the AuthenticationMethod is "password", see line 180 in WsFederationPlugin\ResponseHandling\SignInResponseGenerator.cs:

if (validationResult.Subject.GetAuthenticationMethod() == Constants.AuthenticationMethods.Password)
    {

        mappedClaims.Add(new Claim(ClaimTypes.AuthenticationMethod, AuthenticationMethods.Password));
        mappedClaims.Add(AuthenticationInstantClaim.Now);

    }

Arbitrary values for ClaimTypes.AuthenticationMethod seem to trouble either AD FS or shibboleth, I would suggest AuthenticationMethods.Unspecified for anything not password:

if (validationResult.Subject.GetAuthenticationMethod() == Constants.AuthenticationMethods.Password)
{
    mappedClaims.Add(new Claim(ClaimTypes.AuthenticationMethod, AuthenticationMethods.Password));
}
else
{
    mappedClaims.Add(new Claim(ClaimTypes.AuthenticationMethod, AuthenticationMethods.Unspecified));
}
mappedClaims.Add(AuthenticationInstantClaim.Now);

for AAD/O365 federation

see here: http://zamd.net/2015/02/06/federating-azure-ad-with-thinktecture-identity-server-notes/

While trying to get the meta data using the latest version (2.3.0), it is throwing the below error. However it works fine with the version 2.0.5. Below is the error.

Error (using 2.3.0)

Success (using 2.0.5)

http://zamd.net/2015/02/06/federating-azure-ad-with-thinktecture-identity-server-notes/

WsFederation package declares dependency as Thinktecture.IdentityServer.v3 (≥ 1.0.0-beta2)
But IdentityServer has broken this dependency in beta3-4 by commit
Updated to LibLog 1.3 nuget package (09eb6ef4b62c521ab3b2b01f55d33b71d929f717)

Specifically - type ILogExtensions was replaced by LogExtensions.

Hi,

The WsFederation plugin seems to lack support for OwinEnvironmentService. If I understand it correctly the WsFederation AutofacConfig lacks the OwinEnvironmentService setup from the Core AutofacConfig:124. But since the OwinEnvironmentService constructor is internal, it's not as simple as just adding support for it in the WsFederation plugin.

This is an issue if your UserService uses the OwinEnvironmentService, since the SignInResponseGenerator in the WsFederation plugin requires UserService, and thus won't be able to resolve the dependency, causing an exception to be thrown.

Victor

Currently the sign out process when using WS-Fed dead-ends in a logged out page because it does not use the reply URL if it was provided.

The change itself is fairly simple and straightforward: if there is a Reply URL, make a SignOutMessage, write it, and include the ID on the logout redirect...but the constructors for MessageCookie are internal.

When I upgraded from Beta 4 to RC I got 404 on /wsfed/metadata. I thought that it might have moved, but I couldn't find where and the samples does not seem to point on any other location.

I am using IdSrv in the same process with this configuration:

        app.Map("/sts", stsApp =>
                        {
                            var factory = InMemoryFactory.Create(null, Clients.Get(), Scopes.Get());
                            factory.UserService = new Registration<IUserService>(new MyInMemoryUserService(Users.Get()));

                            var options = new IdentityServerOptions
                                          {
                                              IssuerUri = "XXX",
                                              SiteName = "XXX",
                                              RequireSsl = false, //Test

                                              SigningCertificate = Certificate.Get(),
                                              Factory = factory,

                                              AuthenticationOptions = new AuthenticationOptions
                                              {
                                                  IdentityProviders = ConfigureAdditionalIdentityProviders
                                              },
                                              PluginConfiguration = ConfigurePlugins
                                          };

                            stsApp.UseIdentityServer(options);
                        });

    private void ConfigurePlugins(IAppBuilder app, IdentityServerOptions options)
    {
        var factory = new WsFederationServiceFactory
        {
            UserService = options.Factory.UserService,
            RelyingPartyService = new Registration<IRelyingPartyService>(typeof(InMemoryRelyingPartyService))
        };

        factory.Register(new Registration<IEnumerable<RelyingParty>>(RelyingParties.Get()));

        var wsFedOptions = new WsFederationPluginOptions
        {
            IdentityServerOptions = options,
            EnableMetadataEndpoint = true,
            Factory = factory
        };

        app.UseWsFederationPlugin(wsFedOptions);

    }

As you can see I have also tried to set EnableMetadataEndpoint explicitly.

I am trying to have IdSrv encrypt the assertion sent to a certain relying party. I load a .cer file with the certificate of the RP, and set it on the relying party definition:

new RelyingParty
{
    Realm = "urn:client",
    Name = "Client name",
    Enabled = true,
    ReplyUrl = "https://localhost:44303/wtrealm",
    TokenType = TokenTypes.Saml2TokenProfile11,
    TokenLifeTime = 30,
    IncludeAllClaimsForUser = true,
    EncryptingCertificate = Certificate.LoadClientCertFromCerFile() // X509Certificate2
}

I then get the following exception when IdSrv is trying to issue the assertion:

ID4178: The EncryptingCredentials provided in the SecurityTokenDescriptor is for an asymmetric key. You must use an EncryptedKeyEncryptingCredentials to encrypt the token.

I'm not having acr_values carry through to my user service when using ws-fed.

Are these not enabled for the ws-fed plugin or do you only use standard ws-fed parameters?

FYI I'm after the Tenant acr_value in particular

Is there Federation Metadata endpoint? I tried the common one:
https://localhost:44308/identity/FederationMetadata/2007-06/FederationMetadata.xml
but to no avail.
I also included EndpointSettings in my WsFederationPluginConfiguration:

        var wsFedOptions = new WsFederationPluginOptions
        {
            IdentityServerOptions = options,
            Factory = factory,
            MetadataEndpoint = new EndpointSettings { IsEnabled = true }
        };

Tried also with the static property:

        var wsFedOptions = new WsFederationPluginOptions
        {
            IdentityServerOptions = options,
            Factory = factory,
            MetadataEndpoint = EndpointSettings.Enabled
        };

still https://localhost:44308/identity/FederationMetadata/2007-06/FederationMetadata.xml returns 404.

I would like to force a user to sign-in again by revoking the issued tokens if for instance the user needed to be blocked/barred with immediate effect.

Is there a way to do this?

So that a WS-Fed config doesn't have to know to set IdentityServerOptions and UserService on the WsFederationPluginOptions.

Documentation says to set the RelyingPartyTokenLifeTime in hours but SignInResponse.CreateSecurityToken() uses the value as minutes:

Lifetime = new Lifetime(DateTime.UtcNow, DateTime.UtcNow.AddMinutes(validationResult.RelyingParty.TokenLifeTime))

The default metadata does not have these two descriptors.

There doesn't seem to be any way to "turn them on"?.

If you want to use e.g. ADFS as the IDP, when you import the default metadata, ADFS throws an error because the Descriptor elements are missing.

Is there any way to add these to the metadata?

Hi,

When using IdentityServer3 version 2.0.0-rc1 and IdentityServer3.WsFederation version 2.0.0-beta1 the wsfed endpoint throws the exception:

Unhandled exceptionSystem.TypeLoadException: Could not load type 'IdentityServer3.Core.Extensions.OwinExtensions' from assembly 'IdentityServer3, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null'.
   at IdentityServer3.WsFederation.WsFederationController.<Get>d__0.MoveNext()
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at IdentityServer3.WsFederation.WsFederationController.Get() in c:\etc\Dropbox\identity\IdentityServer3\WsFederation\source\WsFederationPlugin\Configuration\Hosting\RequestResponseLogger.cs:line 0
   at lambda_method(Closure , Object , Object[] )
   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass12.<GetExecutor>b__8(Object instance, Object[] methodParameters) in c:\etc\Dropbox\thinktecture\IdentityModel\source\Core\Metadata\FederationMetadata.cs:line 0
   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments) in c:\etc\Dropbox\thinktecture\IdentityModel\source\Core\Metadata\FederationMetadata.cs:line 0
   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken) in c:\etc\Dropbox\identity\IdentityServer3\WsFederation\source\WsFederationPlugin\Configuration\Hosting\RequestResponseLogger.cs:line 0

IdentityServer3.Core.Extensions.OwinExtensions does not exist in the release candidate, this was changed to IdentityServer3.Core.Extensions.OwinEnvironmentExtensions in IdentityServer/IdentityServer3@948eebed and IdentityServer/IdentityServer3@766a3f9e

As far as I can tell, IdentityServer3.WsFederation just needs rebuilding against IdentityServer3 2.0.0-rc1?

I'm keep getting this error:
The target "MSDeployPublish" does not exist in the project.

GetProfileDataAsync(ProfileDataRequestContext context) in InMemoryUserService fails when the relying party has IncludeAllClaimsForUser == true. This seems to be because dentityServer3.WsFederation.ResponseHandlingSignInResponseGenerator.CreateSubjectAsync creates a new ProfileDataRequestContext without setting its AllClaimsRequested to true. This makes InMemoryUserService perform a Contains() on the ProfileDataRequestContext.RequestedClaimTypes which is not set because all claims where requested.

Stacktrace:
at System.Linq.Enumerable.Contains[TSource](IEnumerable1 source, TSource value, IEqualityComparer1 comparer)\r\n at System.Linq.Enumerable.Contains[TSource](IEnumerable1 source, TSource value)\r\n at IdentityServer3.Core.Services.InMemory.InMemoryUserService.<>c__DisplayClassd.<GetProfileDataAsync>b__b(Claim x) in c:\ballen\github\identity\IdSrv3\IdentityServer3\source\Core\Services\InMemory\InMemoryUserService.cs:line 133\r\n at System.Linq.Enumerable.WhereListIterator1.MoveNext()\r\n at System.Collections.Generic.List1..ctor(IEnumerable1 collection)\r\n at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source)\r\n at IdentityServer3.Core.Services.InMemory.InMemoryUserService.GetProfileDataAsync(ProfileDataRequestContext context) in c:\ballen\github\identity\IdSrv3\IdentityServer3\source\Core\Services\InMemory\InMemoryUserService.cs:line 133\r\n at IdentityServer3.WsFederation.ResponseHandling.SignInResponseGenerator.<CreateSubjectAsync>d__c.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\ResponseHandling\SignInResponseGenerator.cs:line 99\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at IdentityServer3.WsFederation.ResponseHandling.SignInResponseGenerator.d__1.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\ResponseHandling\SignInResponseGenerator.cs:line 57\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at IdentityServer3.WsFederation.WsFederationController.<ProcessSignInAsync>d__b.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 152\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at IdentityServer3.WsFederation.WsFederationController.d__0.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 81\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Threading.Tasks.System.Web.Http607580.TaskHelpersExtensions.<CastToObject>d__31.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Web.Http.Filters.ActionFilterAttribute.d__5.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Web.Http.Filters.ActionFilterAttribute.d__5.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Web.Http.Filters.ActionFilterAttribute.d__5.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at System.Web.Http.Filters.ActionFilterAttribute.d__5.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Web.Http.Controllers.ActionFilterResult.d__2.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Web.Http.Controllers.AuthenticationFilterResult.<ExecuteAsync>d__0.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0\r\n--- End of stack trace from previous location where exception was thrown ---\r\n at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext() in c:\ballen\github\identity\IdSrv3\IdentityServer3.WsFederation\source\WsFederationPlugin\WsFederationController.cs:line 0

To validate signout request (like we do for the OIDC endpoint).

If I have 2 relying parties with 2 different claims specified in the claim mapping. I.E.
Relying Party: urn:site1
Claim: Site1UserId http://site1.com/claims/UserId

Relying Party: urn:site2
Claim: Site2UserId http://site2.com/claims/UserId

If I login from site 1 and go to site 2 it will show site 1 UserId and visa versa.

How do i prevent this, or is this a bug?

To allow the <form> to submit.

The IUserService registration for WsFederationServiceFactory is currently set by the registration in IdentityServerServiceFactory, however it has a public setter.

Is this intended? I've attempted to set a different user service here but I'm met with various InvalidOperationException errors as the two user services clash.

I'm using an IdentityServer OWIN configuration with an WS-Federation plugin configured.
The server's URL : https://root.openid.md/
The RP's URL:

1. https://client.openid.md/
2. http://bistro.md/
3. http://lunch.md/

The RP's are configured exactly as (MVC OWIN WS-Federation example).

The Single Sign In works excellent. But when it comes to SSO, there is a significant delay, about ~ 1 min.

Scenario from Trace.log file:

1. I'm SignIn to all RP's (one of them requires Login and Password, others are being automatically signed in)
2. I'm performing an LogOut from https://client.openid.md/
3. The Signout Page from http://root.openid.md/ appears after which I click Sign Out.
4. Other RP's are still signed in. I'm constantly refreshing any page (including with [Authorize] attr.) of any remaining RP's, and approximatively after 1 min, they are being signed out.

The Trace.log file is below:
https://drive.google.com/file/d/0B_QAgAHaOvE2N29yaFZ0Q1pDdEU/view?usp=sharing

We are able to successfully login to the client SPA application using our IdP server (IdentityServer3 1.6.3 + Microsoft.Owin.Security.WsFederation 3.0.1) with different providers.
But logout with endsession endpoint doesn't redirect to post_logout_redirect_uri for windows authentication flow.
After logout the page is redirected to https://idphost/IdP/?wtrealm=urn%3aidp%3alocal&wa=wsignout1.0 instead of client address which was set in post_logout_redirect_uri.
Setting wreply didn't help, only added this param with value to ACS WS-Federation endpoint.