WIF STS, разные "виды" пользователей, приложений и претензий

Question

В настоящее время мы рассматриваем возможность внедрения собственной STS (Microsoft WIF) для аутентификации наших пользователей, и в ходе этого процесса у нас возникло несколько вопросов, на которые мы не смогли ответить.

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

Допустим, все пользователи авторизованы с использованием простого https с использованием имени пользователя и пароля (.NET MVC3). Пользователь уникально идентифицируется по его типу, имени пользователя и паролю (не только имя пользователя и пароль). Поэтому мне нужно будет создать конечную точку для каждого типа пользователя, чтобы иметь возможность различать их. Когда пользователь авторизуется, я выдаю токен, содержащий утверждение, представляющее тип пользователя. Есть ли более простой способ сделать это? Можно ли избежать конечной точки для каждого типа пользователя (в настоящее время их три)?

Моя служба токенов может затем проверять токен авторизованных пользователей и преобразовывать утверждения, выдавая токен, содержащий все утверждения, относящиеся к типу пользователей. Пока все хорошо, за исключением нескольких конечных точек, я думаю?

Если мне нужно иметь несколько конечных точек, должен ли я также предоставлять различные документы метаданных, по одному для каждой конечной точки? Наличие одного большого документа метаданных, содержащего описание всех утверждений, не имеет никакого смысла, поскольку не существует приложения, которому требуются все утверждения.

Обновление

Некоторые уточнения.

Некоторые приложения используются только определенными типами пользователей. Ни одно приложение не может использоваться несколькими типами пользователей.

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

Answer 1

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

Так что, imho, это будет действительный сценарий для трех STS или STS с несколькимиконечные точки.

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

Последовательность обработки может выглядеть следующим образом:

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

Структура базы данных / класса для этого может выглядеть примерно так:

Answer 2

Нужна дополнительная информация, чтобы ответить:

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

Откуда происходит тип пользователя?Если из репозитория вы не могли бы просто создать заявку на него?

Обновление:

@ Решение Питера должно работать.

Wrt.3 STS против 3 конечных точек,

Многие STS - могут использовать одну и ту же стандартную конечную точку с разным «выделением кода».Все равно будет работать, если вы перешли на готовое решение.Дополнительная работа по продлению сертификатов.

Один STS - пользовательские конечные точки не смогут быть перенесены.Для обновления сертификатов требуется только один STS.

Метаданные - учитывая, что они могут генерироваться динамически, на самом деле не имеют значения.См. Динамическое создание метаданных федерации .