Ваш вопрос отличный:
Как мне создать согласованную структуру авторизации для решения этой проблемы для приложений такого типа?
Ответ заключается в том, чтобы положитьсяна внешней структуре авторизации.Есть несколько вариантов для достижения этой цели.Некоторые из них являются специфичными для .NET, некоторые - общего назначения.
В целом, это поле известно как Управление доступом на основе атрибутов (ABAC).ABAC дает вам:
- архитектура
- язык политики, на котором вы выражаете свое разрешение (например, " менеджеры могут просматривать документы в своих отделах ")
- протокол запроса / ответа, по которому отправляются запросы на разрешение / запрещение.
Архитектура ABAC
На этом рисунке показано, как работает ABAC: у вас есть понятие точки перехвата или точки применения (PEP), которая перехватывает поток между пользователем и приложением.Эта точка контроля будет проверять, может ли пользователь получить доступ к тому, к чему он хочет получить доступ (данные, вызов API, виджет ...).Идея состоит в том, что PEP является локальным по отношению к тому, что вы защищаете, но принятие решений централизовано, и это то, что даст вам последовательное разрешение.У вас могут быть PEP для SPA, для API ... И они могут последовательно применять одни и те же политики авторизации.
Точка принятия решений PDP или Policy - это та, которая обрабатывает запросы на авторизацию и оценивает их в соответствии с набором политик.ты бы ранее написал.Языковые политики написаны, как правило, alfa или xacml .
PIP (Точка информации о политике) является абстрактным представлением ваших источников данных и пользовательских каталогов (AD,БД ...) где вы можете хранить дополнительную информацию о пользователях и ресурсах.Они могут быть полезны, чтобы помочь принять правильное решение.
Опции
Вы можете выбрать реализацию с открытым исходным кодом, например, AuthZForce или коммерческую реализацию, например, Аксиоматика (где я работаю)..NET Core также имеет авторизацию на основе политик , но это не поможет вам с вашим SPA.