identityserver / identityserver4.wsfederation Goto Github PK

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

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

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

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?

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?

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

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?

As mentioned here , could the aspnetcore version, IdentityServer4 version be upgraded to the respective latest versions?

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.

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.

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?