5

When using WIF, the client is able to set the persistentCookiesOnPassiveRedirects which by default is false. Here is the provided definition:

persistentCookiesOnPassiveRedirects: Specifies whether persistent cookies are issued when the module is enabled to initiate WS-Federation passive protocol redirects. A persistent cookie will outlast user sessions.

OK that sounds clear, but I still do not get it and changing the value between true/fasle does not seem to make any difference. Does it have anything to do about pulling up another site in a separate browser that trusts the same STS provider and making it so the user does not have to log in again?

I suppose an example of a site and STS working together would be really helpful to explain exactly what this setting does. Thanks!

atconway
  • 20,624
  • 30
  • 159
  • 229
  • 1
    I'm guessing if you were using passive redirects you would notice it making a difference. http://stackoverflow.com/questions/5452488/how-do-i-increase-session-timeout-with-w-i-f-saml-tokens-fedauth-cookie – Steve's a D Oct 25 '12 at 16:38
  • I am using passive redirects, but have not done testing for length of time until expiry. Is that the main advantage to setting this value to 'true'? – atconway Oct 25 '12 at 17:53
  • No idea, I know as much about WIF as an ape knows about calculus – Steve's a D Oct 25 '12 at 19:31

1 Answers1

4

It means that the FedAuth cookies issued by WIF will be persistent (as opposed to tied to a user session). If you close the browser and open it again, the cookies will still be sent to your site and token negotiation will not happen (you will not be redirected to the STS).

If it is false, each time you close the browser and open it again the negotiation will be triggered, because there's no token anymore. (Cookies is where WIF stores the information of the security token).

Notice that the STS itself will also issue cookies (different from your app) and those might be persistent, so the actual authentication might not happen the second time even if you set the flag to false.

Notice also that WIF can optionally store the information it needs somewhere else (server side).

Last but not least, the token might expire, in that case the negotiation will be triggered regardless of the flag.

Eugenio Pace
  • 14,094
  • 1
  • 34
  • 43
  • Your comment: **Notice that the STS itself will also issue cookies (different from your app) and those might be persistent, so the actual authentication might not happen the second time even if you set the flag to false.** Is there a way to control this as well? That last bit your wrote I have experienced and unable to explain. – atconway Oct 25 '12 at 19:35
  • 1
    If you have control of the STS, then yes. (The STS is not your app)ACS for example doesn't allow it and will always forward your request to the IdP (e.g. Google). If you set the "remember me" flag, then cookies are persisted and you would not need to re-authenticate. – Eugenio Pace Oct 25 '12 at 20:41
  • Yes the STS provider is mine (both ends are). What is the configuration element within the *STS Token Provider* passive login site that would control this? – atconway Oct 25 '12 at 21:12
  • Do you know which element in the STS provider configuration itself controls this? – atconway Nov 01 '12 at 12:19
  • Sorry for not being very clear. Are you using an off the shelf STS? (e.g. ADFS, IdentityServer, etc). You need to check with their docs. If you built it yourself, then you have full control and you would use the standard (e.g. MVC, APS.NET) APIs to issue persistent cookies. Makes sense? – Eugenio Pace Nov 01 '12 at 17:15
  • Kind of - I used the website template installed with the WIF SDK named 'ASP.NET Security Token Service Web Site' to create my STS Provider. Do you know the specific setting for this STS provider is? I didn't see this type of setting on the STS side is why I ask (only see it on the consuming client). – atconway Nov 01 '12 at 17:25
  • 1
    Got it. I would not recommend using that in production :-). But to answer your question: WIF has nothing to do with that, because the WIF is there just to give you a token. Authentication is happening through some other mechanism (e.g. membership). Use ASP.NET API to create a persistent cookie and your done. – Eugenio Pace Nov 02 '12 at 01:29
  • Any reason to steer clear of the WIF generated code by this project template for production? If the passive login is secured via HTTPS is there something natively wrong with the classes it creates for issuing tokens via WIF? – atconway Nov 02 '12 at 14:24
  • 1
    Just a warning on it being fairly bare template. A "real" STS would have to be tested for perf/scale, security, manageability, etc. IN the same way a "new project" project is also not production ready. I think the intent was to enable development mostly, but it might be that you did all that (testing, etc). – Eugenio Pace Nov 02 '12 at 16:07