Определить роли от Azure ACS

Question

Как мы знали, в Интернете было много учебников для Azure ACS, но большинство из них останавливается на вставке простых ACS на веб-сайт или приложение. Теперь я задаюсь вопросом, можно ли идентифицировать и связать всех известных пользователей oauth-провайдера и добавить их новому пользователю в базу данных, а затем назначить им роль? После процесса они просто нажимают на любого провайдера, а затем возвращают их в ту же учетную запись? Есть ли у вас такой учебник? Вот поток процессов, который я хочу сделать: Окно в прямом эфире + Google + Yahoo + Facebook, у одного человека может быть все четыре счета, но тогда мне также нужна их информация, затем я создаю данные о вводе данных в cuatom, и проблема в том, как можно Я соединяюсь? Как удалить уникальный идентификатор для идентификации? Поэтому я могу узнать его .. и назначить ему роль.

Вопрос 1: как соединить?

Вопрос 2: как идентифицировать систему?

Вопрос 3: как дать роль? Не давая от лазурного странице администратора, но через код

Thx

Answer 1

Существует одна вещь, которую вы должны знать, при работе с ОКС (и с претензиями в целом) - вы должны получить знать Claims.

Теперь, для конкретного вопроса ACS. Служба управления доступом Windows Azure - это не волшебная палочка, которая будет делать то, что вы хотите автоматически. ACS - это самый простой способ работать с претензиями и работать только с одним набором конкретных требований и не беспокоить всех разных реализаций разных протоколов. На самом деле то, с чем вы работаете, при создании приложения на основе браузера, равно WS-Federation protocol (и SAML token по умолчанию, но вы также можете использовать токен SWT), а не протокол OAuth. Уникальность пользователя вы получаете, когда кто-то входит в с вашего сайта, при использовании ACS является строгое сочетание следующих двух факторов:

• личность пользователя
• ACS namespace

Уникальность вы получаете NameIdentifier claim (представлено: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier).

Первый улов, что, скажем, я «john.doe@gmail.com», идентифицированный на вашем сайте через http://yourcompany.accesscontrol.windows.net, вы получите идентификатор имен «X». Когда, я, тот же «john.doe@gmail.com» идентифицирую себя на вашем сайте, через http://yourcompany-live.accesscontrol.windows.net/, вы получаете идентификатор имен «Y»! И это справедливо для всех поставщиков удостоверений, которые вы связываете через свою службу контроля доступа.

Второй улов: поставщик идентификации идентификатора Live ID, при настройке через ACS, предоставит вам только заявку NameIdentifier. И больше ничего.

Теперь вопросы:

Вопрос 1: как связать?

Единственный возможный способ связывания идентификаторов - это построить свою собственную логику привязки в своем приложении. Что бы я сделал, это прекратить использовать все автоматически сгенерированный код и пассивное перенаправление для ACS, но для обработки некоторых из пассивной федерации вручную. Это означало бы - я буду следить, вошел ли пользователь в систему или нет. Если вы не вошли в систему, я перенаправляю пользователя на мою собственную страницу входа, где я получаю от ACS настроенные параметры входа.Когда пользователь войдет в систему, я создам запись в моей собственной базе данных пользователей для этого пользователя. У меня будут поля (или связанные таблицы) для всех возможных поставщиков удостоверений, которые я бы хотел связать с одним пользователем. Поймите, я буду хранить все имена NameIdentifiers, которые могут быть у пользователя. Теперь, как я могу связать учетную запись пользователя. Могут быть разные подходы. Во-первых, вы должны указать пользователя, чтобы он мог связать учетную запись. Затем создайте, скажем, «билет на связь» с некоторым уникальным идентификатором (а не GUID, который легко запомнить пользователь). Покажите этот идентификатор пользователю и предложите ему войти в систему с другим провайдером (получить список приспешников из ACS). Когда пользователь приходит с другим провайдером - показывает поле, когда можно ввести билет. Проверьте билет, и если он действителен - перейдите к существующей учетной записи.

Вопрос 2: как идентифицировать систему?

Как уже упоминалось в answe один - вам нужно будет иметь свою собственную базу данных пользовательских пользователей, где вы будете иметь одну учетную запись для каждого пользователя, но учетная запись будет содержать все требования NameIdentifier, выданные различными органами. Таким образом, вы сможете однозначно идентифицировать пользователей со связанными атрибутами.

Вопрос 3: как дать роль? Не давая от лазурной страницы администратора, но через код

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

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