WS Federation exception (wctx parameter missing) in AD FS 2.0

[bin0m]

Hi Dominick,

Can you please assist me?

I decided to use your Idsrv v2 for my solution.
General idea was to move authentication logic from the application to separate STS. Initially AD FS 2.0 fited us very well, because we store our user data in AD.
But then was decided to add possibility of authentication via Google,Facebook,Twitter,... So I thought to add your Idsrv (as IP-STS), and connect it to ADFS (as RP-STS).

Flow:
--> User redirected to Adfs, choose login via Idsrv
--> Redirected to Hrd page of Idsrv, clicks Facebook button
--> Redirected to Facebook login page, enters credentials
--> Facebook authenticates user, send user claims back to Idsrv
--> Idsrv sends email claim to Adfs
(here it crashes, Adfs exception: "The WS-Federation Passive protocol parameter 'wctx' was not found or not valid" )
--> Adfs adds additional claims based on the user's email
--> RpApp will get all claims of the user

Now I'm out of ideas. I'm stucked few days on that problem:
Adfs exception: "The WS-Federation Passive protocol parameter 'wctx' was not found or not valid"

Interesting, when I change configuration in ADFS2.0: WS-Federation Endpoint for Claim provider from https://idsrv.mydomain.com/idsrv/issue/hrd to https://idsrv.mydomain.com/idsrv/issue/wsfed. It works! But it isn't what I need. My RP app just gets claims of Idsrv user. Pretty useless for me.
Here is my setup:

Idsrv2 (as IP-STS): idsrv.mydomain.com

Relying party configuration for ADFS 2.0:
-Display Name: ADFS
-Realm/Scope Name: https://adfs.mydomain.com/adfs/services/trust
-Redirect Url: https://adfs.mydomain.com/adfs/ls/

Identity Provider Configuration:
Facebook, Google (as in the example: http://brockallen.com/2012/11/04/oauth2-in-thinktecture-identityserver-oauth2-identity-providers/)

Protocol WS-Federation:
Enabled: true
Enable Sign-in: true
Enable Federation: true
Enable Home Realm Discovery: true
Allow ReplyTo parameter: false
Require ReplyTo within Realm: false
Require SSL: false

Protocol WS-Trust:
Enabled: true
Enable Message Security Endpoints: false
Enable Mixed Mode Security Endpoints: true
Enable Client Certificates Authentication: false
Enable Federated Authentication: false
Enable Identity Delegation: true

Protocol Oauth2:
Enabled: true
Enable Implicit Flow: false
Enable Resource Owner Flow: false
Enable Consent Page: true
ADFS2.0 (as RP-STS): adfs.mydomain.com

Claim Provider Configuration:
-Display Name: idsrv.mydomain.com
-Identifier: https://idsrv.mydomain.com/idsrv/trust/
-WS-Federation Endpoint: https://idsrv.mydomain.com/idsrv/issue/hrd

RP Configuration:
-Display Name: MvcTestApp
-WS-Federation Endpoint: https://adfs.mydomain.com/MvcTestApp/
MvcTestApp (RP): VS2012 Template MVCApplication

Thank you in advance,
Gregory

[brockallen]

Ok, I just tried to repo and I can't. My only guess is that you're losing some cookies and that's why the wctx is getting lost. Maybe you can debug a little more and look into the cookie issue as a possibility?

[brockallen]

Any updates? If I can't get any help in reproducing this, then I'll have to close the issue.

[bin0m]

I looked into Idsrv code. Didn't find anything suspicious. It just seems like HRD (in Idsrv) doesn't support something in federation protocol, that's why ADFS throws 'wctx' exception.
But I don't know those protocols good enough, to see what is missing.

Tell me how can I help to reproduce it?

P.S. Meanwhile, I managed to switch IP-STS to Azure ACS 2.0, which works fine in the same flow.

[leastprivilege]

Could you trace the whole interaction with fiddler and upload the trace file. That would help.

[leastprivilege]

Can you provide a trace?

[bin0m]

Sorry for late response. Was very busy this week.

Here is fiddler trace:
http://www.speedyshare.com/FXH6e/adfs-idsrv-hrd2.saz

Here is ADFS error in eventviewer:

Encountered error during federation passive request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.InvalidWSFederationContextException: MSIS7045: The WS-Federation Passive protocol parameter 'wctx' was not found or not valid. If the context was stored in cookies, the cookies that were presented by the client were not valid. Ensure that the client browser is configured to accept cookies from this website and retry this request.
at Microsoft.IdentityServer.Web.EncodedContext.GetContextParamValue(String contextPart, String paramName, ContextType contextType)
at Microsoft.IdentityServer.Web.EncodedContext.InitializeWSFederationPassiveProtocolContext(Uri baseUrl, String encodedValue)
at Microsoft.IdentityServer.Web.EncodedContext..ctor(String encodedValue, Boolean samlEnabled, Boolean wsFederationEnabled)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.ParseRelyingPartyInfoFromWCtx(String wctx, Boolean deleteCookie, String& contextId)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.GetOriginalRequest(FederationPassiveContext federationPassiveContext, Boolean deleteCookie, String& requestId)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.GetOriginalRequest(Boolean deleteCookie, String& requestId)

[brockallen]

I've started to debug the fiddler trace logs. For some reason your ADFS is issuing a different form of wctx than mind. Your ADFS issues "BaseUrl%3dhttps%253a%252f%252fadfs.infratel.com%252fadfs%252fls%252f%5cwtrealm%3dhttps%253a%252f%252fadfs.infratel.com%252fMvcTestApp%252f%5cwctx%3drm%253d0%2526id%253dpassive%2526ru%253d%25252fMvcTestApp%25252f%5cId%3did-405b1d66-971f-4b74-b266-eb53df1e4ef0" where as mine only issues a GUID like "0a5355db-d4a2-4e0f-b486-1fd24ac4b88a".

I'm still investigating...

[brockallen]

Ok, so even though I could not repro your issue due to my ADFS not issuing similar wctx params, I think I did discover a URL encoding bug in the HRD code. It wasn't a problem for WIF when we redirect back to a normal RP, but I'm guessing that ADFS gets cranky when the URL encoding doesn't match exactly. I think that's what you were experiencing so with this check-in (5e130bb), please re-test. Thanks.

[leastprivilege]

OK?

[brockallen]

Ok, I think I'll close this. If @bin0m finds an issue, they can re-open.