Блог

В настоящее время у нас есть простой веб-сайт AspNet Core, на который входит «Менеджер». Это дает им доступ к данным о филиалах компании, которыми они управляют, и о клиентах, которые используют эти филиалы.

У менеджеров есть учетная запись в нашей организации Azure AD. В настоящее время мы используем некоторые разрешения, определенные при регистрации приложения на веб-сайте. У нас есть разрешение для каждой ветви под названием «BRANCHNAME_Managers», это больше похоже на группу. По памяти я думаю, что у нас были проблемы с доступом к группам, в которых находился пользователь, изнутри веб-сайта, поэтому мы использовали утверждения в том виде, в каком они указаны в ClaimsPrincipal.Claims.

Мы хотим создать API, который вызывается с этого веб-сайта. Этот API должен знать, какими филиалами управляет менеджер. Этот api будет иметь отдельную регистрацию приложения в Azure AD, и, похоже, что разрешения, настроенные при регистрации приложения на веб-сайте, не будут переданы в веб-api. Поэтому я думаю, что нам нужно отказаться от разрешений, определенных при регистрации приложения на веб-сайте. Правильно ли это?

Принимая во внимание то, к чему мы пытаемся контролировать доступ, филиалы, которыми управляет менеджер, и клиенты, связанные с этими филиалами, должны ли мы использовать членство в группах пользователей или что-то, что мы используем сами с помощью простых связей с базой данных?

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

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

Затем вы можете проверить роли приложений, включенные в маркер доступа для вашего API.