WsFederation SaveTokens does not work

[dsmailys]

Hello,

Tried using WsFederationOptions.SaveTokens = true, but the token is not being set in the AuthenticationProperties.

I have tried hooking into Events.OnSecurityTokenValidated
and saving token into authentication properties myself by
properties.StoreTokens (new [] { new AuthenticationToken { Name = tokenClaimName, Value = token } });
but with no luck. I get

This site can’t be reached
The webpage at https://localhost:44301/ might be temporarily down or it may have moved permanently to a new web address.
ERR_SPDY_PROTOCOL_ERROR

Am I missing something here?

[Tratcher]

You're not missing anything, SaveTokens is an inherited option that hasn't been implemented for WsFed yet.

ERR_SPDY_PROTOCOL_ERROR is not what I'd expect for an application error. Disable this code and verify the rest of your site is still working as expected.

Can you share more of your OnSecurityTokenValidated code for context?

[dsmailys]

If I disable the SaveTokens implementation - the rest of the site is working as intended.
I have a wrapper class that wraps around WsFederationHandler and adds some code for authentication from authorization header, but this might be out of scope.
I hook into the events like this:

public async Task InitializeAsyncWrapper (AuthenticationScheme scheme, HttpContext context)
            {
            await base.InitializeAsync (scheme, context); 
            Events.OnSecurityTokenValidated = OnSecurityTokenValidated;
            }

private Task OnSecurityTokenValidated (SecurityTokenValidatedContext securityTokenValidatedContext)
            {
            var token = securityTokenValidatedContext.ProtocolMessage.GetToken ();
            var claimsIdenity = securityTokenValidatedContext.Principal.Identity as ClaimsIdentity;
            claimsIdenity.AddClaim (new Claim ("TokenType", token));
            return Task.CompletedTask;
            }

If I add non base64 encoded token to the claims, I get

Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.

If I encode the token to base64 before storing it into the claims:

private Task OnSecurityTokenValidated (SecurityTokenValidatedContext securityTokenValidatedContext)
            {
            var token = securityTokenValidatedContext.ProtocolMessage.GetToken ();
            var encoded = System.Convert.ToBase64String (System.Text.Encoding.UTF8.GetBytes (token));
            var claimsIdenity = securityTokenValidatedContext.Principal.Identity as ClaimsIdentity;
            claimsIdenity.AddClaim (new Claim ("TokenType", encoded));
            return Task.CompletedTask;
            }

I get

The webpage at https://localhost:44301/ might be temporarily down or it may have moved permanently to a new web address.
ERR_SPDY_PROTOCOL_ERROR

Note that I clear the cookies (and not using the authorization header implementation) before the requests to get the code triggered.

Tried saving the token to the AuthenticationProperties:

private Task OnSecurityTokenValidated (SecurityTokenValidatedContext securityTokenValidatedContext)
            {
            var token = securityTokenValidatedContext.ProtocolMessage.GetToken ();
            securityTokenValidatedContext.Properties.StoreTokens (
                new[] {new AuthenticationToken {Name = "TokenName", Value = token}});
            return Task.CompletedTask;
            }

And I get:

Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.

Tried encoding the token:

private Task OnSecurityTokenValidated (SecurityTokenValidatedContext securityTokenValidatedContext)
            {
            var token = securityTokenValidatedContext.ProtocolMessage.GetToken ();
            var encoded = System.Convert.ToBase64String (System.Text.Encoding.UTF8.GetBytes (token));
            securityTokenValidatedContext.Properties.StoreTokens (
                new[] {new AuthenticationToken {Name = "TokenName", Value = encoded } });
            return Task.CompletedTask;
            }

And I get:

This site can’t be reached
The webpage at https://localhost:44301/ might be temporarily down or it may have moved permanently to a new web address.
ERR_SPDY_PROTOCOL_ERROR

If I am not messing with the claims and authenticationProperties, I get a working application.
Might it be related to some cookie checks for integrity etc?

[Tratcher]

Wrapping the handler is a strange way to set OnSecurityTokenValidated, you could have set that in Startup.

How big is the token? It sounds huge. A Fiddler trace would show how big the cookie gets when you do this.

I don't have a good explanation for the protocol error, it sounds like a catastrophic failure on the server. Is there anything showing up in the server logs?

[dsmailys]

Yes, I could, but this is not the main purpose of the wrapper. The main purpose is to enable authentication through authorization header on an api call with a token in the authorization header.

1st scenario:
When I am not saving the token and getting a redirect from IdentityProvider to my application:
Status code: 302, localhost:44301/, Body size: 0.
Request sending 82 bytes of Cookie data: .AspNetCore.Correlation.WsFederation
Response: 1) 142 bytes of Cookie data: .AspNetCore.Correlation.WsFederation
2) 68 bytes of Cookie data: .AspNetCore.Cookies=chunks-2
3) 4049 bytes of Cookie data: .AspNetCore.CookiesC1
4) 881 bytes of Cookie data: .AspNetCore.CookiesC2
Status code: 200, localhost:44301/, Body size: 30 (just simple data from the app)
Request sending 4882 bytes of Cookie data:
1) .AspNetCore.Cookies=chunks-2
2) .AspNetCore.CookiesC1
3) .AspNetCore.CookiesC2

2nd scenario:
When I am saving the token (as is) to the authentication properties with StoreTokens method and getting a redirect from IdentityProvider to my application:
Status code: 302, localhost:44301/, Body size: 0.
Request sending 82 bytes of Cookie data: .AspNetCore.Correlation.WsFederation
Response: 1) 142 bytes of Cookie data: .AspNetCore.Correlation.WsFederation
2) 68 bytes of Cookie data: .AspNetCore.Cookies=chunks-5
3) 4049 bytes of Cookie data: .AspNetCore.CookiesC1
4) 4049 bytes of Cookie data: .AspNetCore.CookiesC2
5) 4049 bytes of Cookie data: .AspNetCore.CookiesC3
6) 4049 bytes of Cookie data: .AspNetCore.CookiesC4
7) 354 bytes of Cookie data: .AspNetCore.CookiesC5
Status code: 400, localhost:44301/, Body size: 346
Request sending 16388 bytes of Cookie data. (sending same 5 chunks)

3rd scenario:
When I am saving the token (base64 encoded) to the authentication properties with StoreTokens method and getting a redirect from IdentityProvider to my application:

I did notice a very strange behaviour. Once I open Fiddler to capture traffic, I get Bad Request - Request Too Long screen, but once Fiddler is closed, I receive the ERR_SPDY_PROTOCOL_ERROR. I did reproduce this multiple times in a row.

Status code: 302, localhost:44301/, Body size: 0.
Request sending 82 bytes of Cookie data: .AspNetCore.Correlation.WsFederation
Response: 1) 142 bytes of Cookie data: .AspNetCore.Correlation.WsFederation
2) 68 bytes of Cookie data: .AspNetCore.Cookies=chunks-6
3) 4049 bytes of Cookie data: .AspNetCore.CookiesC1
4) 4049 bytes of Cookie data: .AspNetCore.CookiesC2
5) 4049 bytes of Cookie data: .AspNetCore.CookiesC3
6) 4049 bytes of Cookie data: .AspNetCore.CookiesC4
7) 4049 bytes of Cookie data: .AspNetCore.CookiesC5
8) 165 bytes of Cookie data: .AspNetCore.CookiesC6
Request sending 20210 bytes of Cookie data. (sending same 6 chunks)

The token itself is 8542 bytes long (non encoded).

I could not see anything abnormal in the logs.
I can attach full trace log if there is a need for it.

[Eilon]

@dsmailys we don't recommend storing this data in any persistence because it is security-sensitive information (akin to a username/password). Can you provide more info on the scenario you're trying to achieve?

[dsmailys]

This is mainly used when a service wants to call another service that requires authentication.

On full framework we had an option of BootStrapTokenClaimName where we could specify a claim name and store the token.
Do you think we could tackle this in different manner @Eilon ?
Is there some sort of a workaround to pass the token to the controller action until the enhancement is implemented? @Tratcher

[Tratcher]

ClaimsIdentity has a BootstrapContext, not sure what's in it for WsFed though. @brentschmaltz

[Eilon]

@brentschmaltz - can you share your thoughts on this?

[dsmailys]

Tried saving the token to the BootstrapContext in OnSecurityTokenValidated event.

private Task SecurityTokenValidated (SecurityTokenValidatedContext context)
    {
    TrySaveTokenToBootstrapContext (context.ProtocolMessage.GetToken(), context.Principal.Identity as ClaimsIdentity);
    }

private void TrySaveTokenToBootstrapContext (string token, ClaimsIdentity claimsIdentity)
            {
            if (Options.SaveTokens && claimsIdentity != null)
                {
                claimsIdentity.BootstrapContext = new BootstrapContextToken (token);
                }
            }

But when I get to the authorized Controller action, BootstrapContext is null. Is it being overwritten somehow? Maybe I am not using the BootstrapContext correctly?
@Tratcher

[jeff-bacon]

I'm trying to fetch the access token after login and somehow instantiate a WindowsIdentity from it for the purpose of impersonation. I can't figure out how to get the access token though. Tried the bootstrap context and savetokens = true with no luck.

[dsmailys]

@Tratcher I've got some additional information.
Our team found out that if we host the application on Kestrel web server with configured https and self signed certificate, we are able to add token to the user claims and receive the modified claimsPrincipal in the action with no additional modifications.

Beforehand I tested the application by hosting it on local IIS. Might it be related to the IIS configuration and maybe we can workaround it?