Azure ACS — внедрение передового опыта

Мы создаем приложение 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 Membership Provider? Как лучше всего удовлетворить наши требования?


azure asp.net-mvc-3 acs wif
person Francesco    schedule 31.01.2012    source источник

Ответы (2)


arrow_upward
9
arrow_downward

Что касается части вопроса об этапе регистрации, лучше всего использовать для идентификации пользователей тип утверждения 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

person Mike Goodwin    schedule 01.02.2012

arrow_upward
1
arrow_downward

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

После настройки 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 с электронной почтой «[email protected]».

Теперь в вашем приложении 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

person Andrew Lavers    schedule 31.01.2012
comment
Андрей большое спасибо за ответ. Что касается ролей в ACS, я был прав, в основном мы не можем связать пользователя с ролью, как мы можем сделать в провайдере членства .net (UsersInRoles), но мы можем связать роль на основе IP. А на этапе регистрации? Что мы должны хранить в нашей базе данных, чтобы распознать пользователя (как часть наших клиентов) на этапе аутентификации? - person Francesco; 01.02.2012
comment
Нет, я хочу сказать, что вы можете связать пользователей с ролями с помощью ACS. Я расширил свой ответ выше, чтобы охватить это. - person Andrew Lavers; 01.02.2012