We’re using ADFS (on Windows Server 2012 Datacenter edition) in RP-STS mode configured for WS-Federation passive sign
in. There are multiple RPs, and multiple upstream IP-STSs configured.
The desired behaviour is as follows:
1. User browses to first RP, and is redirected to ADFS.
2. ADFS displays home realm discovery page, and user chooses IP-STS.
3. ADFS stores session cookie “MSISIPSelectionSession” to remember the choice the user made.
4. ADFS sends sign in request to chosen IP-STS, which authenticates the user, and issues sign in response to ADFS.
5. ADFS issues sign in response to RP, Windows Identity Foundation takes care of the rest.
6. User browses to 2nd RP, and is redirected to ADFS.
7. ADFS uses the IP-STS choice made previously, via the “MSISIPSelectionSession” session cookie.
8. ADFS sends sign in request to chosen IP-STS, which authenticates the user, and issues sign in response to ADFS.
9. ADFS issues sign in response to RP, Windows Identity Foundation takes care of the rest.
This all works nearly perfectly, with one really strange problem:
The “MSISIPSelectionSession” session cookie is created correctly at step 3, but it’s then cleared at step 5 when ADFS issues
the sign in response to the RP. This means that when the user browses to the 2nd RP and is redirected to ADFS, they’re re-presented with the home realm discovery page rather than the previous selection being used automatically.
The documentation on ADFS configuration (http://msdn.microsoft.com/en-us/library/ee895366.aspx) suggests that this should
all work as desired:
Persist Identity Provider Selection. This element specifies how long to
save the user’s selection of the Identity Provider STS (IP-STS). By default, the selection is stored in a persistent cookie for 30 days. This saves the user from having to specify the IP-STS every time he or she signs in. The following element saves the selection
for 90 days:
<persistIdentityProviderInformation enabled="true" lifetimeInDays="90" />
Set the enabled attribute to false to track only the Identity Provider selection for the current browser session. In that case, you do not have to specify the lifetimeInDays attribute.
<persistIdentityProviderInformation enabled="false" />
Our configuration is based on the latter example.
I’ve looked at the ADFS source code, and it’s clear why the cookie is being created and then subsequently deleted:
The SendSignInRequest method (in Microsoft.IdentityServer.Web.FederationPassiveAuthentication, Microsoft.IdentityServer.dll,
6.2.9200.16645) makes the following method call, which maps to step 3 of the behaviour flow:
FederationPassiveAuthentication.SaveIPSelectionSessionCookie(identityProvider.SamlEntityId.OriginalString);
The SendSignInResponse method (in Microsoft.IdentityServer.Web.FederationPassiveAuthentication, Microsoft.IdentityServer.dll,
6.2.9200.16645) makes the following method call, which maps to step 5 of the behaviour flow:
FederationPassiveAuthentication._ipSelectionCookieManager.DeleteSessionCookie();
I’m unable to understand why a call to the DeleteSessionCookie method is made when issuing the response. I’ve applied all
available updates, and been reading documentation, forums, blogs etc. for days to try and understand, but I’ve not found examples of anyone else that’s come across this issue.