В будущем мы планируем внедрить архитектуру микросервисов. Мы не хотим, чтобы разрешения на шлюзе API были очень громоздкими и ограниченными для ПОЛУЧЕНИЯ, РАЗМЕЩЕНИЯ, ПУБЛИКАЦИИ и т.д.

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

Я включил изображение проекта архитектуры, который у меня есть в голове, а также логический поток ниже.

Мой вопрос

Может ли этот шаблон проектирования быть реализован с использованием любой из существующих спецификаций аутентификации / авторизации, таких как OAuth2? Если нет, допустимо ли создать свой собственный шаблон аутентификации / авторизации для использования в частной сети?

Жизненный цикл приложения

1. Разработчик создает веб-приложение 1
2. WebApp1 зарегистрирован разработчиком на сервере реестра веб-приложений. Он / она также регистрирует пользовательские разрешения, которые предоставляет приложение.
3. ИТ-администратор может предоставить или отозвать доступ к детализированным разрешениям, предоставляемым приложением.

В приведенном выше примере WebApp1 предоставляет два разрешения CreatePost amp; DeletePost user1 , имеет разрешение только на CreatePost

Поток пользовательских процессов

1. Не прошедший проверку подлинности пользователь получает доступ к WebApp1 и перенаправляется на экран входа в систему.
2. Учетные данные пользователя проверяются на соответствие LDAP и генерируется токен авторизации UUID. Токен хранится на сервере токенов безопасности, и пользователь перенаправляется обратно в WebApp1 с токеном, включенным в заголовок авторизации.
3. WebApp1 запрашивает разрешения, имеющиеся у этого пользователя, с сервера реестра веб-приложений, это может выполняться каждые x минут, и сохраняет их в локальном состоянии. Сервер реестра веб-приложений также проверяет, что токен авторизации все еще действителен.
4. WebApp1 проверяет каждые x минут, что токен пользователя все еще действителен, если пользователю не предлагается снова войти в систему (или токен обновления может быть включен в исходный токен, который был отправлен в приложение при аутентификации пользователя).

Интересный вопрос — ниже приведены некоторые мысли о достижении ваших целей с помощью шаблонов проектирования на основе OAuth:

ЦЕЛЬ АВТОРИЗАЦИИ

Желаемое конечное состояние обычно заключается в том, чтобы предоставить вам выбор:

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

СОПОСТАВЛЕНИЕ ТОКЕНОВ С РАЗРЕШЕНИЯМИ

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

В моем посте авторизации API описывается расширяемый шаблон, который начинается с определения утверждений / основного объекта в каждом API. Вот некоторый пример кода, где класс Authorizer предоставляет обзор поведения при каждом запросе API.

РЕЕСТР ВЕБ-ПРИЛОЖЕНИЙ

Я бы с осторожностью относился к созданию компонентов, которые могут оказаться под большой нагрузкой и стать узким местом для всей вашей программной платформы — нужен ли вам один из них?

ПРЕТЕНЗИИ И МИКРОСЕРВИСЫ

Шаблон, который может хорошо работать, заключается в разработке 2 уровней API. Интересно, что оба они могут использовать утверждения, и вы можете распределить обязанности по авторизации в любом месте, где захотите, и предоставить себе выбор:

• API точки входа: доступны для Интернета, выполняют проверку OAuth и, естественно, блокируют то, что клиенты могут делать с токенами доступа:

• Микросервисы: запускаются в заблокированной сети и могут свободно вызывать друг друга без подключения OAuth

В моем посте «Архитектура платформы API» рассматривается этот параметр, при котором утверждения передаются между микросервисами через заголовки.

ДЕЙСТВИТЕЛЬНОСТЬ ТОКЕНА ДОСТУПА

Часто вы можете упростить код, следуя приведенным ниже правилам, поскольку может быть несколько причин, по которым токены становятся недействительными:

• Сохраняйте токены доступа недолговечными ~ 60 минут
• Обработайте 401 ошибку в клиенте, как в этом коде