Настройка ролей Azure ACS

Question

Эй, ребята, не уверен, что это подходящий форум для этого, но я нахожусь в своем уме, пытаясь понять это.

Итак, быстрый фон того, что я пытаюсь сделать. Я работаю над моим старшим проектом для колледжа, и это на самом деле с Microsoft, но мое приложение для веб-форм выполнено. Я пытаюсь настроить ACS с определенной идентификацией на основе ролей. Я использую VS 2012, и я получил ACS для правильной работы с использованием Windows Live Id и входа в Google. Моя проблема возникает, когда я пытаюсь ограничить все приложение только пользователями, которые являются администраторами. Я видел много обучающих онлайн, но все они, похоже, были с VS 2010, который сильно отличается от 2012 года. Моя проблема заключается в том, что я не могу просмотреть идентификатор имени, что Windows live id дает мне возможность сыграть роль из это в лазури. Так, например, если в журнале some@live.com я могу получить обратно nameidentifier = "x", а затем сделать роль из этого идентификатора имени. Кажется, у меня нет возможности просмотреть идентификатор имени?

Кто-нибудь знает, как заставить это работать в vs 12 или иметь какие-либо учебники? Или, если кто-то знает способ сделать то, что я объясняю по-другому, я бы очень признателен!

Любая помощь очень ценится!

Также я видел много работы от @AntonStaykov, но не совсем то, что я ищу, если вы тоже здесь, чтобы помочь, я бы очень признателен.

Answer 1

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

 ClaimsPrincipal p = System.Threading.Thread.CurrentPrincipal as ClaimsPrincipal; 

     Claim cNameIdentifier = p.Claims.First(c => c.Type == ClaimTypes.NameIdentifier); 
     if (cNameIdentifier != null) 
     { 
      string NameIdentifierValue = cNameIdentifier.Value; 

      // your code here to implement your logic. 

     } 

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

1. получить входящие претензии NameIdentifier,
2. поиска в магазине (словарь, сохранялся магазин, поставщик и т.д.), чтобы увидеть, если пользователь является администратором, основанным на вашей собственной логике,
3. добавить роль претендента на принципала с «Администратором» в качестве значения.

Является ли это вашей целью? Если это так, то место, где нужно сделать это, находится в ClaimsAuthenticationManager.

http://msdn.microsoft.com/en-us/library/system.security.claims.claimsauthenticationmanager.aspx

-Rick

Answer 2

Инструментарий действительно отличается в VS 2012, если вы настроили таргетинг на .NET Framework 4.5. В значительной степени это обусловлено тем фактом, что Windows Identity Foundation встроена в структуру в 4.5. Таким образом, вы можете устранить некоторые ваши трения, если вы просто нацелились на .NET Framework 4.0. При этом у вас будет аналогичный опыт с учебниками, к которым вы также обращаетесь (при условии, что эти учебные пособия предназначены для .NET 4.0 или более ранних версий).

Я не уверен, почему вы не можете просмотреть идентификатор имени. Может быть, вы можете предоставить немного больше контекста вокруг этого вопроса? Например, вы находитесь на портале ACS, в коде и т. Д.?

-Rick

Answer 3

Основной проблемой у вас есть, использует Live ID (или, как они называют его сейчас - Microsoft Account). Невозможно получить электронную почту пользователя из Live ID, если вы просто используете ACS.Я лично люблю ACS и использую его, я просто не забочусь о учетной записи Microsoft или обрабатываю ее другими способами.

Если вы хотите ограничить доступ ко всему приложению только для администраторов, вы должны сделать две вещи: правила авторизации

1. Setup в вашем system.web разделе, дающие доступ только Administrator роли
2. Настройка претензии Правило в ACS для генерации Administrator заявки на роль на основе некоторых входных критериев.

Шаг один довольно легко, просто добавьте следующую строку внутри system.web раздела в файле web.config:

<authorization> 
    <allow roles="Administrator" /> 
    <deny users="?" /> 
</authorization> 

Просто убедитесь, что нет никакого другого authorization раздела в вашем web.config!

Второй шаг, легкая часть. Перейдите на портал управления ACS, затем перейдите в Rule Group, которая назначена для вашего приложения-получателя. И добавить новое правило со следующими критериями:

1. Выберите поставщика удостоверений для правила (давайте предположим, Google)
2. Выберите тип входного Claim быть: http://schemas.xmlsoap.org/claims/EmailAddress
3. Введите значение претензии: your_desired_admin@gmail.com (адрес электронной почты администратора)
4. Выберите тип выходного претензии быть: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
5. Введите значение для вывода требования: Administrator
   1. Установите правильное описание правила, что-то вроде your_desired_admin@gmail.com is Administrator.
6. Сохраните правило.

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

Существует тривиальный способ предоставления разрешения администратора для держателей учетных записей Microsoft, когда они поступают через Azure ACS. Единственное, что у вас есть это имя Идентификатор претензии или http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (я буду называть его NIC для простоты

NIC уникален по следующей комбинации:.. User Identity (me@live.com) + ACS NameSpace + Relying Party Application Это означает, что если me@live.com лог-инов на ваш приложение через mygreat.accesscontrol.windows.net вы получите для этого пользователя уникальную NIC. Если те же самые пользовательские логины на моем сайте через someother.accesscontrol.windows.net, я получу совершенно новый NIC, который будет глобально уникальным снова, но не будет таким же, как один ваша заявка получена.

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

Вы можете получить претензию NameIdentifier в своей логике приложения, как уже указывал Рик, но действительно ли вы хотите предоставить всем и любым пользователям роль «Администратор»? Плюс, я бы ушел от того, чтобы оставить мое приложение в беспорядке с Правилами в ACS для каждого входа в систему. Есть лучшие способы добиться того, чего вы хотите (как я уже сказал, время для ведения блога).