Azure ACS - реализация лучшей практики

Question

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

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

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

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

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

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

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

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

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

Answer 1

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

После того, как вы установили 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 («Менеджер»), либо эквивалент web.config.

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

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

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

Answer 2

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

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

Это должно быть уникальным для каждого поставщика удостоверений, а также фиксирована. Если вы используете заявку на адрес электронной почты, она может измениться для одного и того же пользователя. Технически это может быть возможно для двух провайдеров удостоверений не использовать один и тот же NameIdentifier (ни один из них из-из-коробки с ОКС делать), чтобы вы могли совместить требование 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