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

Configuration: ADFS 2.0 as IdP (both WS-Federation and SAML 2.0 are supported), ASP.NET application as a service provider. When SPS requests ADFS with the WS-Federation standard (using WIF), it allows me to automatically log into ADFS without a login pop-up, even if a new session starts, so the Kerberos token does its job as expected. However, when using SAML 2.0 (ComponentSpace.SAML.2 lib) every time I open IE9 and redirect to ADFS, I am asked to enter my Windows domain credentials in a standard small login pop-up window. Is there any SAML 2.0 parameter or other way that allows me to get rid of this window, as is the case with WS-Fed? Thanks

+5
source share
4 answers

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

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

You can add the name adfsserver.us.mycompanyname.com to the list of trusted sites (or intranets) and you should not ask for credentials.

+7
source

You can change the passive endpoint server by following these steps:

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

  • Open ADFS 2.0 Service Manager
  • Select "Change Federation Service Properties ..." in the upper right corner. This brings up the federation service properties window.
  • URL- (IdPURL), SSO.
+2

: urn:federation:authentication:windows : urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport SAML 2.0:

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

+1

, , , , . , , SAML , , (WS-Federation/SAML2). / adfs, , https://adfsserver.us.mycompanyname.com/adfs/ls, , https://adfsserver/adfs/lsno. However, I cannot use the short domain name for SAML 2.0, I get an error in this case: "MSIS1006: configured passive endpoint https://adfsserver.us.mycompanyname.com/adfs/ls/" is not a prefix of the incoming SAML Destination message URI 'https: // adfsserver / adfs / ls /' ". By the way, we only use SSO on our local intranet, so I don’t know why this exception occurs. Any workaround?

+1
source

All Articles