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

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, e.g.:

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?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 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.)


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x