Предоставление «новых» пользователей с несколькими доверенными STSes

Question

При использовании Windows Identity Foundation (WIF) с несколькими службами Token Services (STS) можно ли предоставлять пользователям доступ к первому приложению?

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

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

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

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

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

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

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

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

Примечание: Это похоже на this question и this question.

Answer 1

При использовании Windows Identity Foundation (WIF) с несколькими службами Token Services (STS) можно предоставить пользователям доступ к первому приложению?

Ответ: Да, если у вас есть способ identitfying этих пользователей (например, их электронная почта)

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

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

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

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

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

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

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

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