Предоставление «новым» пользователям нескольких доверенных STS - PullRequest
1 голос
/ 02 мая 2011

При использовании Windows Identity Foundation (WIF) с несколькими службами маркеров безопасности (STS) можно ли подготовить пользователей до того, как они впервые получат доступ к приложению?

Например, допустим, у меня есть веб-сайт под названиемBufferOverrun, где пользователи могут входить в систему и задавать / отвечать на вопросы, а я хочу поддерживать аутентификацию с внешними учетными записями Google.Когда пользователь впервые заходит на страницу, он должен пройти аутентификацию с помощью своей учетной записи Google, после чего он может получить доступ к веб-приложению.В этом сценарии есть два службы STS: Google (для аутентификации личности) и одна для моего приложения (для авторизации).

Как я могу назначить заявки пользователю до того, как пользователи получат доступ к системе?

Поскольку удостоверение принадлежит моему приложению извне, я не могу назначить заявки непосредственно этому удостоверению (и в любом случае я бы не хотел, поскольку они были бы специфичны для приложения).Но так как пользователь не получил доступ к системе, у меня нет внутренней идентификационной информации для назначения претензий.Я вижу два возможных решения:

  1. Подождите, пока пользователь не получит доступ к системе (создавая некоторые заявки по умолчанию для конкретных приложений), затем используйте какой-либо внутренний инструмент обеспечения, чтобы изменить эти заявки по желанию.
  2. Иметь инструмент обеспечения, позволяющий пользователям вручную сопоставлять заявку на идентификацию по умолчанию (например, адрес электронной почты), прежде чем эта идентификация будет аутентифицироваться, вводя ее вручную, чтобы при первом доступе, если идентификация подтверждает эту заявку, конкретный набор заявок на приложенияпредоставлены.

Я вижу несколько проблем как с 1, так и с 2. Для 1 все пользователи имеют некоторый неявный доступ к системе, даже если заявки приложений по умолчанию не допускают функциональности.Похоже, это прекрасно работает для чего-то вроде stackoverflow, когда первоначальная учетная запись имеет определенный набор разрешений, и, когда пользователь использует системы, предоставляются новые заявки.Однако это, вероятно, не желательно для всех приложений.2 подвержен ошибкам, так как требует от администратора ручного указания претензии.

В обоих вышеописанных случаях, как мне предоставить удостоверение, которое имеет доступ к , использовать инициализациюинструмент (т. е. учетная запись администратора)?

. Для этого я предполагаю, что во время установки приложения я требую от пользователя аутентификации и установки требований приложения для этого удостоверения так, чтобы они были такими "административные "привилегии".Это хорошая реализация?

Исторически (я сейчас имею в виду существующее приложение), приложение, специально связанное только с Active Directory.Способ, которым это было обработано, состоял в том, что была встроенная учетная запись администратора (не связанная с AD), которая позволяла пользователю администратора сначала входить в систему.После проверки подлинности с помощью приложения администратора этот пользователь может выполнять поиск пользователей / групп в AD и предоставлять их индивидуально.Любой пользователь / группа, не предоставленные администратором, вообще не будут иметь доступа к системе.Я не вижу, чтобы эта парадигма была применима к использованию внешних STS, таких как Google и т. Д., Поэтому я пытаюсь создать архитектуру, которая позволила бы использовать внешние системы STS.Сохранение возможности поиска STS желательно, но не обязательно.На практике обе задействованные службы STS, вероятно, оба будут Active Directory, использующими федеративные службы.

Примечание. Это похоже на этот вопрос и этот вопрос .

1 Ответ

2 голосов
/ 10 мая 2011

При использовании Windows Identity Foundation (WIF) с несколькими службами маркеров безопасности (STS), можно ли подготовить пользователей до того, как они впервые получат доступ к приложению?

Ответ - да,если у вас есть способ идентифицировать этих пользователей (например, их электронную почту)

В этом сценарии есть два STS, Google (для аутентификации личности) и пользовательский для моего приложения (для авторизации).).

Это часто используется, но не всегда, всегда.Если вы полагаетесь только на Google, то вы можете просто иметь код авторизации в самом приложении (например, классы «AuthorizationManager» и т. Д.).Ценность другого STS заключается в том, что он может быть посредником для нескольких удостоверений (например, Google, LiveID, Yahoo !, независимо от того) и вы можете выполнять некоторые преобразования, связанные с авторизацией.

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

Почему бы и нет?Вы можете определить правило, которое гласит:

«Любой, кто прошел аутентификацию в Google, является« читателем »в App BufferOverrun».Вы даже можете сказать:

«кто-то@gmail.com является« читателем »на BufferOverrun», прежде чем кто-то получит доступ к приложению.

Вы все еще можете использовать оригинальный подход (вне группыучетная запись администратора для настройки).Или вы можете также настроить конфигурацию «начальной загрузки» во время предоставления, определяя, какое утверждение будет идентифицировать пользователей с правами администратора.

Взгляните на пример «Федерация с несколькими партнерами и ACS» (пример 7) в http://claimsid.codeplex.com Мы делаем именно это.

...