Интеграция Azure Active Directory с настраиваемым RBAC - PullRequest
Новая
       51

Интеграция Azure Active Directory с настраиваемым RBAC

0 голосов
/ 19 сентября 2018

У нас есть собственное веб-приложение, которое выполняет управление доступом на основе имени пользователя и связанных ролей, определенных локально и поддерживаемых в локальной базе данных.

Мне нужно интегрировать наше приложение с Azure AD, чтобы использовать единую подпись.(SSO) , чтобы с тем же именем пользователя мы могли интегрироваться и получать доступ к другим приложениям SaaS.Я думаю, что могу достичь этого с помощью «API-интерфейсов Azure ADAL» и «API-интерфейсов Graph».

Однако я хотел бы понять, как определить настраиваемые пользовательские атрибуты и роли для «Azure AD», чтобы совместно использовать атрибуты и роли с нашим приложением после проверки подлинности.Это требуется для нашего веб-приложения для обеспечения контроля доступа (на основе идентификатора пользователя и роли) без локального определения ролей.Я не уверен, как этого добиться?

Пожалуйста, дайте мне знать, если это возможно и каков наилучший вариант для достижения того же.

Ответы [ 2 ]

0 голосов
/ 19 сентября 2018

Вы пометили этот SAML, поэтому я предполагаю, что вы хотите сделать это через пользовательское приложение SAML?

Если это так, вам нужно подготовить Azure AD через API Graph из своего пользовательского репозитория.

Если в Azure AD нет нужного атрибута, создайте атрибут расширения .

В соединении SAML вы можете настроить, какие атрибуты передаются (включая роли).

Примечание: библиотеки ADAL предназначены для OpenID Connect, а не для SAML.

0 голосов
/ 19 сентября 2018

Я хотел бы понять, как определить пользовательские атрибуты и роли для «Azure AD», чтобы они могли делиться атрибутами и ролями с нашим приложением после проверки подлинности.Это необходимо для того, чтобы наше веб-приложение обеспечивало контроль доступа (на основе идентификатора пользователя и роли) без локального определения ролей.

Чтобы реализовать пользовательские настройки, вам нужно ознакомиться с функциональностью, связанной с ролями приложений, в Azure AD.RBAC.Скорее всего, он должен предоставить вам то, что вы ищете.

В дополнение к этому, я видел случаи, когда люди предпочитали делать некоторую логику авторизации, основанную на том, к каким группам принадлежали пользователи.Это просто информация, а не то, что вам нужно сделать.

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

Роли приложений

Документация Microsoft - Роли приложений

Цель . Эти роли определены в Манифесте приложения для приложения, которое разрабатывает ваша организация и которое зарегистрировано в Azure Active Directory.Эти роли очень специфичны для вашего приложения и могут использоваться в коде приложения для реализации логики авторизации для аутентифицированных пользователей.

Пример приложения (который использует эту концепцию и выполняет то, что вы ищетедля) -

Авторизация в веб-приложении с использованием ролей приложений Azure и утверждений о ролях

Краткое объяснение

1)После регистрации приложения в Azure AD вы можете определить пользовательские роли (специфичные для вашего приложения), отредактировав манифест приложения (JSON) в Azure AD.
Вот пример JSON того, как будет выглядеть определение роли приложения: 

"appRoles": 
[
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Creators can create Surveys",
    "displayName": "SurveyCreator",
    "id": "1b4f816e-5eaf-48b9-8613-7923830595ad",
    "isEnabled": true,
    "value": "SurveyCreator"
  },
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Administrators can manage the Surveys in their tenant",
    "displayName": "SurveyAdmin",
    "id": "c20e145e-5459-4a6c-a074-b942bbd4cfe1",
    "isEnabled": true,
    "value": "SurveyAdmin"
  }
]

2) Вы сможете назначать эти роли пользователям / группам / приложениям через портал Azure или программно.(вы можете контролировать разрешенные типы элементов для ролей)

3) Теперь, когда конечные пользователи войдут в ваше приложение, входящий токен Azure AD предоставит вам набор заявок на роли (в зависимости от того, какие роли назначены).пользователю), и вы можете принимать решения об авторизации в своем приложении. 

if (context.User.HasClaim(ClaimTypes.Role, "Admin")) { ... }

Группы

Группы могут состоять из нескольких пользователей или других групп.Опять же, управление группами возможно через портал Azure или программно.

ПРИМЕЧАНИЕ : группы полностью независимы от вашего приложения, т. Е. Группы Azure AD могут и существуют, чтобы служить цели группирования членов, дажебез вашего заявления.С другой стороны, роли приложения очень специфичны для вашего приложения, они мало что значат для кого-либо, кроме вашего приложения.

Пример приложения, которое принимает решения на основе групп

Авторизация в веб-приложении с использованием групп и утверждений Azure AD

...