Got a bug report at work today from a client where we've implemented the login towards a STS system.
The reported error was that when they started working in the CMS(EPiServer) and then after some time pressed publish, they would get redirected to the STS provider and then back to EPiServer causing the content they've added to dissapear(since it wouldn't be saved when they got redirected to the login)
I didn't build this system and I've never worked with STS-systems before(I don't even know if you call it STS-systems or a better name exists, anyhow..)
I looked in the web.config file and found this section:
<microsoft.identityModel>
<service>
<audienceUris>
<add value="https://secret.josef" />
</audienceUris>
<federatedAuthentication>
<wsFederation passiveRedirectEnabled="true" issuer="https://stsprovider.link.here/" realm="https://secret.josef" requireHttps="true" />
<cookieHandler requireSsl="true" />
</federatedAuthentication>
PassiveRedirectEnabled caught my attention so I started googling a bit, if set to true, you instruct WIF's federated authentication module to perform its built in redirection of unauthenticated sessions to the issuer.
So that's the setting responsible for redirecting the user to the STS-provider, great!
Only thing left to do was increasing the time before the user got redirected. I did some more googling and found the following attributes, persistentCookiesOnPassiveRedirects
and persistentSessionLifetime
I added the persistentCookiesOnPassiveRedirects="true"
-attribute to the wsFederation section and the persistentSessionLifetime="0.8:0:0"
-attribute to the cookieHandler section.
<microsoft.identityModel>
<service>
<audienceUris>
<add value="https://secret.josef" />
</audienceUris>
<federatedAuthentication>
<wsFederation persistentCookiesOnPassiveRedirects="true" passiveRedirectEnabled="true" issuer="https://stsprovider.link.here/" realm="https://secret.josef" requireHttps="true" />
<cookieHandler requireSsl="true" persistentSessionLifetime="0.8:0:0" />
</federatedAuthentication>
This means that it will set a cookie with an expiration date of 8 hours in the future instead of using a session cookie. Problem solved :)
Im sure that there's another way to just specify how long the session cookie should be valid for but this did the trick for us!