Indicates that SaveTokens is not supported for WsFederation

[Kahbazi]

#7955

[Tratcher]

Does this really prevent the base class intellisense from showing up?

The reference assemblies need to be updated because you added public API.

error : Generated code is not up to date in src/Security/Authentication/WsFederation/ref/Microsoft.AspNetCore.Authentication.WsFederation.netcoreapp3.0.cs. You might need to regenerate the reference assemblies or project list (see docs/ReferenceAssemblies.md ...)

[analogrelay]

Does this really prevent the base class intellisense from showing up?

I believe it will as long as the variable you are dereferencing is actually of the derived type (WsFederationOptions)

@Kahbazi could you verify this and post a quick screenshot?

[Kahbazi]

It's working!

[Tratcher]

Nice. And if you type in SaveTokens manually and hover over it does the right test come up?

[Kahbazi]

yep

[analogrelay]

Very nice! Thanks @Kahbazi ! We should be able to take it from here.

[kevinchalet]

Why not implementing proper SaveTokens support rather than hiding the config' property? 😄

[Tratcher]

@PinpointTownes What would you save? I was under the impression that the wsfed token wasn't useful beyond sign-in.

[analogrelay]

@aspnet-hello triage https://dev.azure.com/dnceng/public/_build/results?buildId=210299

[aspnet-hello]

This comment was made automatically. If there is a problem contact [email protected].

I've triaged the above build. I've created/commented on the following issue(s)
https://github.com/aspnet/AspNetCore-Internal/issues/2620

[kevinchalet]

@PinpointTownes What would you save?

The RequestedSecurityToken returned as part of the wresult parameter (aka the WS-Fed token 😄).

I was under the impression that the wsfed token wasn't useful beyond sign-in.

Keeping the WS-Fed token is definitely useful for delegation or impersonation scenarios (aka ActAs and OnBehalfOf), where the client will want to "exchange" the initial WS-Fed token with a token it can use itself to access protected resources (typically a WCF service or a REST API).

In the old world, this was achieved by setting saveBootstrapContext to true in the WIF options, so that you could access the token via ClaimsIdentity.BootstrapContext and use things like CreateChannelWithActAsToken or CreateChannelWithOnBehalfOfToken with WCF (or WSTrustChannelFactory manually if you were brave 🤣).

In the new world, it would make sense to store the WS-Fed token as an authentication property, exactly like what the OIDC/OAuth handlers do with access, identity and refresh tokens.

[Tratcher]

@PinpointTownes Reading through the prior thread (aspnet/Security#1716 (comment)) it ended because the tokens were too large and caused the cookie to hit header size limits.

I'm merging this change for now and we can revisit if there's enough interest in those tokens.