Azure ACS - внедрение лучших практик

Question

Привет, ребята, мы создаем приложение ASP.NET MCV 3 с нуля, работающее в Windows Azure. Об уровне аутентификации и авторизации мы думаем использовать Сервис контроля доступа. Я просмотрел несколько статей о ACS, в которых получил основную идею, но у меня все еще есть некоторые сомнения по этому поводу.

Насколько я понимаю, используя ACS, мы передаем процесс аутентификации на аутсорсинг одному или нескольким провайдерам идентификации (IP), в основном мы доверяем другой системе (например, Microsoft Live ID) для аутентификации наших пользователей. Основной процесс очень прост: на этапе аутентификации мы перенаправляем (ACS делает это) пользователя на один из наших «доверенных» IP-адресов, который перенаправляет пользователя (с действительным токеном) в ACS и, в конечном итоге, в наше приложение. Здесь возникает ряд вопросов ...

Поскольку мы не хотим, чтобы все пользователи с учетной записью Live ID имели доступ к нашему приложению, я предполагаю, что должен быть другой процесс для проверки этого пользователя и проверки его регистрации в нашем приложении. Вопрос в том, где? В АСУ или в нашем приложении.

У меня есть идея по этому поводу, но я не знаю, правильно ли это сделать: На этапе регистрации система (наше веб-приложение) запрашивает у пользователя, какой IP-адрес (т. Е. Live ID, Google, Facebook и наше приложение) он хочет использовать для аутентификации в приложении. Затем пользователь проходит процесс аутентификации в системе IP, и когда он возвращается, мы сохраняем его имя пользователя (имя пользователя IP) в нашей БД. Поэтому в следующий раз на этапе аутентификации мы можем проверить, зарегистрирован ли этот пользователь в нашей системе.

Если приведенная выше теория верна, это означает, что в нашем приложении. нам нужно создать нашего провайдера членства для хранения имен пользователей, пришедших с IP-адресов и пользователей, которые выбрали наше приложение. глоток. Я прав? Какова наилучшая практика для разработки вышеуказанного процесса?

Теперь поговорим об авторизации и «ролях». Как это работает с ACS? Управляет ли ACS несколькими ролями на пользователя?

Опять же, насколько я понимаю, с помощью ACS вы можете создать несколько «групп правил», связанных с IP, а не с одним пользователем. Если это правильно, как мы можем управлять ролями пользователей в нашем приложении? Допустим, например, что у нас есть несколько ролей, и наши пользователи могут быть связаны с этими ролями, можем ли мы использовать ASC для управления им?

Итак, заключительные вопросы: Охватывает ли сама ACS весь процесс аутентификации и авторизации? Нужно ли нам использовать поставщика членства .net? Какова наилучшая практика для удовлетворения наших требований?

Большое спасибо за ваш вклад.

Answer 1

Что касается вопроса об этапе регистрации, то для идентификации пользователей лучше всего использовать NameIdentifier тип заявки

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier.

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

http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider

для гарантии уникальности.

В части, касающейся роли, я бы сказал, что использование ACS для выдачи утверждений о роли из общих идентификаторов, таких как Google, будет довольно сложным, если использовать правила преобразования утверждений в ACS для каждого пользователя. Вы должны добавить правило для каждого зарегистрированного пользователя - возможно, это невозможно. Я думаю, что группы правил ACS больше подходят для преобразования утверждений о роли (например, выданных федеративной ADFS). Ваша идея сделать это в вашем приложении лучше ИМХО. В коде место для этого с помощью WIF находится в пользовательском ClaimsAuthenticationManager. Вы переопределяете его метод Authenticate и, основываясь на требовании NameIdentifier из принципа входящего трафика, вы просматриваете свое хранилище данных членства и создаете новый IClaimsPrinciple на основе ролей, которые есть в вашей базе данных членства (т.е. вы добавляете роль претендовать на каждую роль, в которой находится пользователь).

Затем вы принимаете решение об авторизации в пользовательском ClaimsAuthorizationManager. В Интернете есть несколько хороших примеров и информации об этом. Вы можете начать с

http://msdn.microsoft.com/en-us/library/ee748497.aspx

Answer 2

Процесс проверки пользователя выполняется с заявками.

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

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

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

Правила отдельных претензий в ACS относятся к поставщикам удостоверений, которые выдают претензии, а группы правил - нет.Группы правил ассоциируются с RP (вашими приложениями).Группа правил - это просто группа правил преобразования утверждений, которые сообщают ACS: «для этого приложения примените эту групповую политику правил при выдаче токена».

Документы ACS могут многое рассказать о конфигурации правил утверждений ACS, как через веб-портал, так и через службу управления ::

https://msdn.microsoft.com/library/azure/hh147631.aspx

Расширенный ответ:

Допустим, вы используете ACSпройти аутентификацию в приложении ASP.NET, которое использует WIF.Вы должны настроить ACS на выдачу заявки на роль «Менеджер» для пользователя Google с электронной почтой «jdoe@gmail.com».

Теперь в вашем приложении ASP.NET WIF увидит эту заявку на роль и получитпозволяют вам контролировать доступ с помощью HttpContext.Current.User.IsInRole ("Manager") или эквивалента web.config.

Вы можете управлять этими правилами ACS вручную с помощью веб-интерфейса или реализоватьпроцесс регистрации, который добавляет такие правила к ACS программно с использованием службы управления ACS.Некоторые примеры сервисов управления ACS доступны на сайте acs.codeplex.com.

Кроме того, в учебном комплекте для разработчиков удостоверений есть несколько примеров доступа на основе ролей WIF:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14347