Why is ADFS not passing credentials through with Integrated Windows Authentiation?

Question

We have an ADFS 2.0 instance set up. We use it for 3rd party web app single sign-on. Everything works beautifully with the existing app, App1 with SAML 2.0, including IWA pass-through when users are redirected to our ADFS server.

I just configured a second Relying Party Trust for another application, App2, using SAML 2.0. We're using all of the default ADFS settings, including endpoints. On this application's SAML configuration page, I've told it that our SAML endpoint is "https://adfs.mydomain.com/adfs/ls/". Everything works fine, except that users are prompted for credentials; ADFS is not using IWA for these logins.

I'm testing from a local domain-joined workstation using IE9. Internal DNS points to our local domain-joined ADFS server, external DNS points to our DMZ ADFS proxy. "*.mydomain.com" is in the Trusted Sites zone in IE by GPO and is applied. IWA is enabled in IE. IE clears its cache/cookies/history every time I close it. Both applications are using SP initiated sign-on and both send their assertions to the same endpoint URL on our end.

If I attempt to log in to App2 on a clean session, I'm presented with an ADFS login page. If I enter credentials, I'm logged into the app and can proceed.

If I attempt to log in to App1 on a clean session, I'm immediately redirected to ADFS, IWA is passed through, and I'm logged into the app and can proceed.

If I attempt to log in to App2 in the same session after logging in to App1, I'm redirected to ADFS, the existing ADFS login session initiated by App1 is used, and then I'm immediately redirected to the App2's assertion consumer service URL and given an error page.

My best guess is that I'm missing something in the RPT configuration. All that the SP has given me is their consumer service endpoint URL using a POST binding. I had to guess at the claim rules. The SP doesn't use encryption.

App2 Customer service has been... difficult. Their tech support is overseas, so I only get responses once a day around midnight local time. Most of their responses are standard "copy and paste from the KB". They prefer IdP initiated sign-on, but say they support SP initiated - which seems to be true, since SSO does work on a clean session after logging in on the ADFS login page.

Does anybody know what I'm missing?

Solution

The authentication method can be configured and requested. The same identifiers are used in SAML and WS-Fed.

Requested in WS-Fed goes to whr= and in SAML it goes to Authentication Context Class. In SAML it is possible to specify a "Comparison" (exact, minimal, etc., but then you must agree on the order). ADFS does (at this moment) not pay attention to the Comparison attribute.

Often policies can be defined to use specific levels for specific applications (RP/SP). Sometimes it can be configured differently depending on source address etc.

Comments

[paullem]

Take a look at the AuthnRequest of the SAML 2 app. Does it ask for a specific authentication method (Authentication Context Class)? If you don't understand the question then you can post the SAML2 AuthnRequest.

[Thomas]

@paullem - I think that's it, looks like I learned something new :) The auth method is "PasswordProtectedTransport" which, based on some reading, tells ADFS to require a login form. Existing session tokens would be ignored, hence the App2 error if I log into App1 first. They've also specified that comparison should be "Exact". The appropriate fix would be to get the SP to modify their claim to request Windows auth, which they may not want to do. Here's the relevant blog: blog.auth360.net/tag/authncontextclassref

[paullem]

Yes, that is what I expected. It is an interesting topic. With many half-religious views. Not in the least because it assumes that Auth methods can be ordered into more and less secure (minimal etc.). Hardly anybody agrees on the order :-). ADFS does not look at comparison.

[Thomas]

Rewrite your comment into an answer, and I can mark it as done :)