Windows Identify Foundation: 2 токена на основе разных сертификатов, распознаваемых R.Ps

По техническим причинам мы реализовали в нашем приложении два разных веб-сайта STS. Эти STS выдают токены, основанные на разных сертификатах.

У нас есть основное приложение и подмножество приложений, и каждое из них настроено на использование и доверие к одному из этих веб-сайтов STS.

Оба приложения используют имя типа утверждения для установки имени пользователя при входе в систему, которое затем отображается в пользовательском интерфейсе приложений проверяющей стороны.

Моя проблема в том, что если я вхожу в один STS, все в порядке. Когда я вхожу в другое приложение / STS, имя, отображаемое в пользовательском интерфейсе при первом входе, заменяется именем второго входа.

Я могу только предположить, что, поскольку STS используют совершенно разные сертификаты для подписи токенов, они будут игнорироваться проверяющими сторонами, если они не настроены на доверие в файле web.config. Вот как я это настроил.

По отладке вроде все нормально работает. При создании токена используется правильный STS и правильный сертификат.

Я вижу, что существующий файл cookie FedAuth увеличивается, когда я вхожу во второе приложение, поэтому заявки для обоих сеансов добавляются в один и тот же файл cookie.

Я был бы признателен, если бы кто-нибудь мог предложить несколько предложений о том, как сделать токены, выпущенные STS, полностью независимыми друг от друга.

Большое спасибо, Джон


.net asp.net-4.5 wif
person John Mc    schedule 11.04.2013    source источник
comment
Если вы заметили во время отладки, что у вас есть оба токена аутентификации в сеансе, в чем именно ваша проблема? не обрабатывает случай, когда имеется более одного токена?   -  person vittore    schedule 11.04.2013
comment
И что вы называете подмножеством приложений? это подпапка в проекте asp.net?   -  person vittore    schedule 11.04.2013
comment
Проблема в том, что токены разные, и их следует рассматривать как полностью независимые. Изменение типа утверждения в одном токене не должно влиять на другой, но вот что происходит. Я бы подумал, что подписание токенов разными сертификатами гарантирует, что это так. Подмножество приложений - это отдельное приложение, которое размещается в виртуальном каталоге, отличном от основного приложения. Он предлагает подмножество функций, доступных в основном приложении.   -  person John Mc    schedule 11.04.2013

Ответы (2)


arrow_upward
0
arrow_downward

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

Если вы добавите вторую STS в качестве «доверенного эмитента», WIF (в вашем приложении) с радостью примет его токены. «Имя» типа утверждения - это просто то, что сопоставлено со свойством User.Name.

Вероятно, было бы полезно, если бы вы немного подробнее объяснили, что именно вы хотите сделать. Что происходит в вашем приложении, когда кто-то входит в систему с помощью 2-го STS?

person Eugenio Pace    schedule 11.04.2013
comment
Спасибо за ваш ответ. STS основного приложения использует проверку подлинности с помощью форм и запрашивает имя пользователя и пароль, затем извлекает роли из базы данных и заполняет роли как утверждения в токене. Дополнительное приложение использует только проверку подлинности Windows, и поэтому любой пользователь, входящий через него, должен иметь ограниченный доступ. По сути, это приложение для быстрого доступа. Проблема, которую я пытаюсь решить, заключается в том, что, когда пользователь входит в основное приложение, роли заполняются в заявке для вторичного приложения, и пользователь может сделать гораздо больше, чем должен. - person John Mc; 11.04.2013
comment
В ответ на ваш ответ основное приложение имеет выделенную службу STS и доверяет только токенам оттуда. Дополнительное приложение также имеет выделенную STS и доверяет только токенам оттуда. Если обе службы STS основаны на разных сертификатах, то как такое поведение может быть правильным? - person John Mc; 11.04.2013

arrow_upward
0
arrow_downward

Причина такого поведения в том, что ни у одной из проверяющих сторон не было задано имя для файла cookie аутентификации, поэтому они обе использовали «FedAuth». Явно давая им разные имена для использования в cookieHandler, проблема была решена.

<microsoft.identityModel>
<service>
  <federatedAuthentication>
    <wsFederation passiveRedirectEnabled="false" issuer="http://localhost:9006/App.AD_STS/" realm="http://localhost:6542/" requireHttps="false" />
    <cookieHandler requireSsl="false" path="/" name="AD_STS" />
  </federatedAuthentication>
person John Mc    schedule 11.04.2013