Is there a situation when WsFederationAuthenticationOptions WReply and CallbackPath values may not match?

Question

When using ASP.Net OWIN/Katana to set up single sign-on using WSFederation, there exists WReply and CallbackPath properties.

In example projects, these appear to have very similar values when configured within Startup.Auth , eg:

new WsFederationAuthenticationOptions() {
   CallbackPath = "/WsFed-Foo", 
   Wreply = "https://example.com/WsFed-Foo"

Looking at the docs, I see this:

CallbackPath must be set to match or cleared so it can be generated dynamically. This field is optional. If not set then it will be generated from the current request and the CallbackPath.

I appreciate that CallbackPath is optional, but if it needs to match WReply , then why does the Katana have it when it is computed automatically if omitted? Is there a situation where it might be different to WReply?

Answer 1

Maybe what Tratcher posted in Github ( https://github.com/aspnet/Security/issues/1645 ) answers your question?

In case it does, his reply there to the "WsFed confusion between Wreply and CallbackPath #1645" issue was:

When WsFed was ported from Katana it was translation with modest updates, most of the original design and options were preserved. Justin noticed in testing that the modified relationship between CallbackPath and Wreply is confusing and may cause infinite login loops for our customers. Wreply sets the address the identity provider returns to. CallbackPath sets the path the middleware listens on for the reply.

In Katana users could opt to set Wreply and CallbackPath would be derived from that. Neither had a default and if it wasn't set then the middleware would read all form-post requests.

In Core CallbackPath defaults to /signin-wsfed like our other handlers and Wreply has no value. Challenges generate a wreply from the CallbackPath. The confusion comes if someone sets wreply without updating or clearing CallbackPath. The server will reply to a path that the handler isn't listening on, likely resulting in an infinite auth loop or 404.

The motivation for making wreply a public option on WsFed rather than generating the redirect like other providers was that WsFed identity servers were known to be extremely strict on matching the value, to the point of requiring exact casing, etc.. Generating the url from user input may not be sufficient for this check. It's unclear how many customers have run into this mismatch vs those that set wreply because they saw it in a sample.

Not sure what the best path forward here is. We'll see how many users run into it.

I added emphasys to what I think may answer your first question. Regarding your second question, there doesn't seem to be a situation where it makes sense for Wreply and CallbackPath to be incompatible. (Technically, they are always different because CallbackPath - unlike Wreply - is not a full URL.)