Transparent SSO with SAML (IE, SAML 2.0, ADFS, Kerberos authentication)

Question

Configuration is: ADFS 2.0 as IdP (both WS-Federation and SAML 2.0 are supported), ASP.NET app as Service Provider. When SPS requests ADFS with WS-Federation standard (WIF used) it lets me login to ADFS automatically with no login pop-up window even if new session started, so that Kerberos token does its job well as expected. However in case of SAML 2.0 (ComponentSpace.SAML.2 lib is used) every time I open IE9 and being redirected to ADFS, I'm asked to enter my windows domain credentials in a standard small pop-up login window. Is any SAML 2.0 parameter or other technique letting me to get rid of this window like in the WS-Fed case? Thanks

Answer 1

adfsserver.us.mycompanyname.com/adfs/ls is in the Internet zone and the automatic login will not happen.

adfsserver/adfs/ls is in your Intranet zone in IE and will log in automatically.

You could add adfsserver.us.mycompanyname.com to your trusted (or Intranet zone) sites list and you should be not be prompted for credentials.

Answer 2

It's not an answer, it's rather update to my question, but it's important and I decided to put it as an answer to attract more attention to it. What I've figured out playing with the SAML parameters for few days is that it seems to be not depend on protocol (WS-Federation/SAML2). What it actually depends on is long/short adfs server domain name, so that authentication request like https://adfsserver.us.mycompanyname.com/adfs/ls makes this window appear, while https://adfsserver/adfs/ls does not. However I can not use short domain name for SAML 2.0, I'm getting error in the case: "MSIS1006: The configured passive endpoint 'https://adfsserver.us.mycompanyname.com/adfs/ls/' is not a prefix of the incoming SAML message Destination URI 'https://adfsserver/adfs/ls/'". BTW, we use SSO in our local intranet only, so I do not know why this exception occures. Any workaround?

Answer 3

You can change passive endpoint server following steps mentioned below:

http://breakingdevelopment.blogspot.in/2012/12/adfs-msis1006-i-am-working-on-sso.html

1. Open ADFS 2.0 Service Manager
2. Select "Edit Federation Service Properties..." from the top right corner. This brings up the Federation Service Properties window
3. Change the Federation Service Identifier to match the Identity Provider URL (IdPURL) passed from your SSO application.

Answer 4

Try: urn:federation:authentication:windows instead of: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport in this part of the SAML 2.0 authentication request:

<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:authentication:windows</saml:AuthnContextClassRef>