Directory Programming .NET

Hi,

Micorosft changed the value of wctx in the following update: http://support.microsoft.com/kb/971726.

Before this update the definition of wctx was:

The original requested WS resource URL is saved as a context parameter in the sign-in message (wctx).

We used this value to customize the content of the clientlogon.aspx. Using wctx we could determine what the calling application was and from which page of the calling application the clientlogon.aspx was called. Because the definition of wctx has changed we can't dertmine this anymore.

Wreply doesn't give us all the information, it only gives us information about the calling application, not of the page of the calling application.

Is it possible to determine the calling page?

Thanks,

René

 

Unfortunately, the WS-Fed PRP protocol specifies that you must treat wctx as an opaque identifier at the fed server and may only pass it through unchanged. Thus, when this patch went out, it broke you.

Unfortunately, the protocol is not designed so that you know anything other than what's in wreply or wtrealm to make a decision on. If you wanted to have "original URL" context information from the protected app, you would need to find a different way to provide that such as a "domain-wide" cookie issued by the app that the fed server would "see" in the request sent to the fed server. I could imagine you might run into problems with something like that as well, but it seems like your only good option other than having the app set up as multiple different apps (different wreply).

Best luck figuring something out. The patch has been "interesting" for sure. We are still working through some issues internally similar to this.

Rene,
Have you considered adding your own query parm like myapp=xyz to the logon redirect?
That is possible, but it may be a considerable amount of work.
If you remove then you can do the redirect yourself with something like:
SingleSignOnIdentity ssoId = User.Identity as SingleSignOnIdentity;
if ( ! sssId.IsAuthenticated )
{
string s = ssoId.SignInUrl + "&myapp=xyz"
Context.Response.Redirect(s);
}
The tricky part is that all your pages will now need this...
There is also another trick to solve that, but would something like this help you?
There probably is a reason why you did not do this in the past, but I don't remember that reason if there was one.

Paul