Добавление авторизации в OpenID connect - PullRequest
0 голосов
/ 06 мая 2018

Я разрабатываю микросервисную систему, включающую аутентификацию и авторизацию. Я понимаю часть аутентификации с использованием OpenID connect, но мне интересно, как авторизация входит в картину.

Давайте предположим следующую ситуацию: У нас есть пользователь, сидящий в своем браузере и подключающийся к веб-приложению («клиент» или «проверяющая сторона»). Сначала он входит в систему клиента, затем он хочет получить доступ (через клиента) к службе заказов. Однако не каждому пользователю разрешено просматривать заказы, например, только сотрудники отдела продаж могут просматривать заказы.

Для входа в систему пользователь, проверяющая сторона (RP) и провайдер идентификации общаются по OpenID. В конце у RP есть токен идентификатора, идентифицирующий пользователя.

Теперь при доступе к сервису заказа какой-то компонент должен проверять права пользователя. Где находится этот компонент? RP запрашивает права перед тем, как обратиться в службу заказа? Служба заказа спрашивает права пользователя? Какая информация / токены отправляются службе заказов и «компоненту авторизации»?

Я также видел токены доступа в OpenID connect, но, насколько я понимаю, это токены OAuth2, в которых говорится, что владелец ресурса делегировал свои права доступа клиенту. Однако это не относится к моей проблеме, когда у меня нет владельца ресурса, но я хочу проверить, разрешено ли пользователю просматривать заказы. Вероятно, это не является частью OpenID connect, но мне кажется, что это стандартная проблема, хотя я не смог найти примеров для этого.

В случае, если это поможет: я использую ядро ​​ASP .NET и IdentityServer4 для проверки подлинности, а IdProvider является частью моей системы (без стороннего входа в систему). Если другие протоколы лучше приспособлены к этой проблеме, я рад узнать о них!

Ответы [ 2 ]

0 голосов
/ 07 мая 2018

Внутри openID connect (и OAuth) Области используются для определения «ролей» (авторизации) RP.

Сервер авторизации МОЖЕТ полностью или частично игнорировать область, запрошенную клиентом, на основании политики сервера авторизации или инструкций владельца ресурса.

Как пример: Приложение может иметь некоторые ресурсы, которые являются общедоступными для любого Аутентифицированного владельца ресурса, который также является клиентом.

Когда Владелец ресурса использует Social Login, Сервер авторизации может определить, что этот пользователь также является Заказчиком. Политика авторизации гласит, что любому Заказчику может быть предоставлен OAuth Scope «read_premium». Таким образом, сервер авторизации предоставит привилегированной области «read_premium».

0 голосов
/ 06 мая 2018

Вы правы.

«Аутентификация» (например, реализация OpenID в IDServer4) - это механизм проверки того, кем вы являетесь.

«Авторизация» определяет, какие привилегии могут быть предоставлены авторизованному пользователю. Это две разные вещи.

«Авторизация» - это «вещь уровня приложения». Ваше APP определяет:

а) какие роли существуют,

b) как аутентифицированным пользователям назначается роль

в) какие привилегии предоставляются в зависимости от роли.

Для «корпоративных приложений» «Служба каталогов» (например, MS Active Directory) часто используется для сопоставления пользователей с ролями. В других случаях приложение выполняет сопоставление самостоятельно.

Другими словами, после того как вы установили личность пользователя, существует множество способов назначить «привилегии». Лучшее, что я могу предложить, - это подумать о некоем «контроле доступа на основе ролей» (RBAC).

Например:

...