Обнаружение области/роли OpenID Connect

Question

Недавно я узнал, как OIDC предоставляет идентификатор пользователя поверх OAuth 2, а также удалось создать логин OIDC для моего webapp. Однако, когда дело доходит до части авторизации, неясно, как приложение должно знать, какие области запрашивать API?

Например, определенные конечные точки должны быть защищены областью «admin», а соответствующие элементы пользовательского интерфейса должны быть скрыты от пользователей, не являющихся администраторами. Часть правоприменения, которую я могу реализовать, может быть легко реализована, но когда пользователь входит в систему, приложение должно знать, является ли пользователь администратором или нет - например, нужно ли запрашивать область «admin»/показывать связанные с администратором компоненты пользовательского интерфейса.

Есть ли какой-либо стандартный способ представления конкретных приложений в профиле пользователя, который поступает от IDP? Меня больше всего беспокоит то, что такая информация, насколько мне известно, не может быть добавлена ​​в профили пользователей, например Google/Twitter/Facebook, поэтому вам необходимо либо a) дополнительный уровень (IdentityServer/OpenAM/etc), либо b) дополнительные данные профиля пользователя в базе данных webapp.

Моя первая мысль заключалась в том, чтобы добавить пользовательские претензии, выполнив а) - но когда дело доходит до интеграции с существующими ВПЛ, может быть невозможно настроить все профили пользователей (например, крупные корпоративные базы данных), поэтому я принимаю приложение должно быть достаточно гибким, чтобы переводить существующие данные профиля пользователя в «admin/not-admin».

Есть ли лучшее решение?

Answer 1

По моему мнению, не является хорошей практикой основывать ваше разрешение на претензии, возвращенные вашими поставщиками удостоверений. Эта ответственность должна быть делегирована серверу UMA. Ему решать или не предоставлять доступ к защищенному ресурсу. Например, изображение, которое мы имеем следующий сценарий:

Контекст: электронной коммерции предприятие внутренне разработал инструмент, используемый его командой маркетинга, чтобы получить информацию о своих самых преданных клиентов. Приложение разработано в WPF и взаимодействует с RESTFUL API для извлечения клиентов. Только это приложение и пользователи, принадлежащие к маркетинговой группе, имеют право на получение списка.

Проблема: как приложение может получить доступ к защищенной операции?

workflow

Решение: рабочий процесс состоит из трех больших этапов:

• Идентичность маркер: получить маркер идентичности с неявным грантового типа. Маркер возвращается клиенту в качестве параметра обратного вызова
• RPT лексем: маркер идентичности и доступа (справедливо для областей uma_authorization & uma_protection) передаются в запросе для извлечения RPT один. Когда он получен приложением WPF, токен передается в заголовке авторизации для извлечения лояльных клиентов. Оба параметра требуются по политике авторизации.
• Проверить токен RPT: токен проверен на конечную точку интроспекции, эта конечная точка предоставляется сервером UMA.

Как вы можете видеть, внутренние политики используются сервером UMA для предоставления/или отсутствия доступа к ресурсу. Политика авторизации выходит за рамки спецификации UMA, вы должны определить ее самостоятельно: '(. Я разработал продукт (с открытым исходным кодом), чтобы легко управлять политиками авторизации. Если вам интересно, вы можете протестировать демо здесь: http://lokit.westus.cloudapp.azure.com/Demo

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