2012-10-25 2 views
3

При использовании WIF клиент может установить persistentCookiesOnPassiveRedirects, который по умолчанию является ложным. Здесь предусмотрено определение:Что на самом деле делает установка persistentCookiesOnPassiveRedirects на true?

persistentCookiesOnPassiveRedirects: Определяет, будут ли выпущены постоянные куки, когда модуль включен, чтобы инициировать WS-Federation пассивный протокол перенаправляет. Постоянный файл cookie будет внеочередных сессий пользователя.

ОК, это звучит ясно, но я все еще не понимаю его, и изменение значения между истиной/fasle, похоже, не имеет никакого значения. Имеет ли он какое-либо отношение к подтягиванию другого сайта в отдельном браузере, который доверяет тому же провайдеру STS и делает это так, что пользователю не нужно снова войти в систему?

Я полагаю, что пример сайта и STS, работающий вместе, действительно поможет объяснить, что именно делает эта настройка. Благодаря!

+1

Я предполагаю, что если вы используете пассивные переадресации, вы заметите, что это имеет значение. http://stackoverflow.com/questions/5452488/how-do-increase-session-timeout-with-wif-saml-tokens-fedauth-cookie –

+0

Я использую пассивные переадресации, но не провел тестирование на длительность время до истечения срока действия. Является ли это основным преимуществом для установки этого значения в значение «true»? – atconway

+0

Не знаю, я знаю столько же о WIF, как обезьяна знает об исчислении –

ответ

1

Это означает, что FedAuth печенье, выпущенное WIF будет постоянным (в отличие от привязанных к пользовательской сессии). Если вы закроете браузер и снова откроете его, куки все равно будут отправлены на ваш сайт, а согласование токена не произойдет (вы не будете перенаправлены на STS).

Если это неверно, каждый раз, когда вы закрываете браузер и снова открываете его, переговоры будут инициированы, потому что больше нет токена. (Cookies - это где WIF хранит информацию маркера безопасности).

Обратите внимание, что сам STS также выдаст файлы cookie (отличные от вашего приложения), и они могут быть постоянными, поэтому фактическая проверка подлинности может не произойти во второй раз, даже если вы установите флаг в false.

Обратите внимание, что WIF может дополнительно хранить информацию, необходимую ему где-то в другом месте (на стороне сервера).

И последнее, но не менее важное: токен может истечь, в этом случае переговоры будут инициироваться независимо от флага.

+0

Ваш комментарий: ** Обратите внимание, что сам STS также выдаст файлы cookie (отличные от вашего приложения), и они могут быть постоянными, поэтому фактическая проверка подлинности может не произойти второй раз, даже если вы установили флаг в false. ** Есть ли способ контролировать это? Этот последний бит, который вы написали, я испытал и не смог объяснить. – atconway

+1

Если у вас есть контроль над STS, то да. (STS не является вашим приложением) ACS, например, не позволяет его и всегда будет перенаправлять ваш запрос в IdP (например, Google). Если вы установите флаг «помнить меня», файлы cookie сохраняются, и вам не нужно будет повторно аутентифицироваться. –

+0

Да, провайдер STS принадлежит мне (оба конца). Каков элемент конфигурации в пассивном логинном сайте * STS Token Provider *, который бы контролировал это? – atconway

Смежные вопросы