Пользовательские динамические согласия - PullRequest
0 голосов
/ 01 ноября 2018

Я создаю SCA для наших сред с использованием IdentityServer4. Теперь у каждого пользователя есть один или несколько уникальных ресурсов, которые я хочу отображать на экране согласия, чтобы пользователь мог дать согласие на чтение в наших средах.

Я использую IS4 EF для хранения данных. И я добавил несколько конечных точек для добавления данных в базу данных. Но я кое-что запутался в том, как продолжить.

Должна ли быть универсальная область для счетов? Или одна область для каждой учетной записи? Может ли пользователь иметь несколько заявок на одно и то же имя, но с разными данными?

Какова наилучшая практика для достижения этой цели?

1 Ответ

0 голосов
/ 02 ноября 2018

Я не понимаю, что вы создали до сих пор, но я думаю, что вы все усложняете.

Думайте о ресурсе как о логической группе от 1 до n API. Где каждый API может реализовать от 1 до n областей. Область действия может относиться к службе, имеющей определенные функции.

Предположим, у вас есть ресурс Api1. И у вас есть области действия Contacts и Messages. Это означает, что ваш ресурс (который может быть группой от 1 до n API) имеет функциональность, позволяющую что-то делать с контактами и что-то с сообщениями. Где области могут быть реализованы в любом месте ресурса. Вы можете создать один API, который реализует все области, два API, каждый из которых реализует одну область, использовать несколько API, которые реализуют части и части областей, или ссылку на внешний API. Это не будет иметь никакого значения для пользователя.

Обратите внимание, что это зависит от того, нужны ли вам contacts.read и contacts.write или просто contacts. Потому что в первом случае чтение / запись - это не авторизация, а логическое разделение сервисов. В то время как во втором случае авторизация может определять права на чтение / запись.

Пользователь имеет доступ к ресурсу с помощью вашего приложения. Чтобы предоставить приложению доступ к ресурсу (так как клиент запрашивает информацию от имени этого пользователя), пользователь должен дать согласие.

Если пользователь не хочет, то клиенту не разрешен доступ к ресурсу от имени пользователя, и служба не может быть полностью выполнена. Поэтому, если вы не хотите делиться своими контактами, пользователь должен предоставить информацию другим способом или просто не предлагать услугу, поскольку требования недоступны.

С другой стороны, пользователь также является ресурсом, поскольку в заявках пользователя содержится информация о пользователе. Таким образом, пользовательский ресурс также может иметь области видимости, такие как openid, профиль, электронная почта, адрес. Если пользователь не дает согласия на использование профиля, информация должна быть получена другим способом, аналогичным ситуации с ресурсом API.

Но между областями есть различия. Например, Openid является обязательной областью, поскольку он содержит (как минимум) подпретензу, необходимую для идентификации пользователя. Это минимальное требование, которое не может быть отменено. Единственная альтернатива для пользователя - нажать No Thanks, что означает, что пользователь решает не использовать приложение.

Итак, у вас есть API и клиент (например, приложение MVC). API может иметь от 1 до n областей, а приложение mvc может запрашивать от 1 до n областей (как из API, так и из пользовательских ресурсов).

Вы также можете расширить IdentityServer в качестве ресурса. И под этим я не имею в виду конечные точки, но как фактический API. Вы даже можете создать отдельный API для этого. Просто настройте API, добавьте области действия и настройте клиент.

Предположим, я добавляю IdApi в качестве ресурса и область действия Account. Эта область доступна для всех пользователей, но используя авторизацию на основе ресурсов, вы можете определить точный уровень доступа, который имеет пользователь (и, следовательно, приложение). Вы можете установить область при необходимости.

Таким образом, учетная запись не может быть привязана к пользователю, поскольку область является дочерним элементом ресурса. Не путайте прицелы с ролями. Область не имеет ничего общего с самой авторизацией. Области запрашиваются клиентом, а роли привязаны к пользователю. И да, вы можете добавить несколько претензий одного типа, например, роль = администратор, роль = менеджер. Это приведет к коллекции ролей. Но это не то, что вам нужно в этом случае.

Как API, так и области идентификации используются в качестве фильтра для пользовательских утверждений. В случае профиля все утверждения, соответствующие типу в списке разрешенных типов утверждений, будут добавлены в токен при условии, что клиент запросил область действия.

API проверяет имя ресурса (aud), а не имя области. Для проверки областей вы можете использовать события, промежуточное ПО и политики.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...