Какой вариант для единого входа (SSO) лучше выбрать, и каким образом оптимально организовать взаимодействие между сервисами?

Question

Виталий

проектирование-программного-обеспечения

Какой вариант для единого входа (SSO) лучше выбрать, и каким образом оптимально организовать взаимодействие между сервисами?

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

1. Какое решение для авторизации и регистрации предпочтительнее использовать: Keycloak или разработать собственное решение?

2. Как организовать взаимодействие между сервисами, когда, находясь в сервисе создания задач, нужно получить список исполнителей? Как обеспечить безопасность при обращении к сервису авторизации за данными пользователей? Следует ли разрешить доступ ко всем авторизованным пользователям, чтобы они могли запрашивать эти данные, и передавать токен пользователя в запросе далее? Также важно отметить, что сервис задач может взаимодействовать с несколькими другими сервисами внутри организации.

3. Существуют ли системы единого входа (SSO), которые используют статические токены без срока действия, хранящиеся, к примеру, в Redis? Какие недостатки могут быть у таких токенов по сравнению с JWT?

Помимо этого, уточняю стек разработки: пользовательский интерфейс на Blazor WASM, сервисы на ASP.Net Core Web API.

6 сентября 2024 г. 18:03

Ответы на вопрос 1

Похожие вопросы

Answer 1

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

### 1. Выбор между Keycloak и собственным решением

**Keycloak**:
- **Преимущества**:
  - Простота внедрения: Keycloak предоставляет много готовых функций (авторизация, аутентификация, управление пользователями и ролями).
  - Поддержка стандартов: Keycloak поддерживает OAuth2, OpenID Connect, SAML.
  - Масштабируемость и расширяемость: уже настраивается для работы в корпоративной среде, легко интегрируется с разными сервисами.
  - Сообщество и документация: имея активное сообщество, Keycloak может снизить время на решение проблем.

- **Недостатки**:
  - Затраты на обучение: команда может потратить время на изучение Keycloak и его функционала.
  - Внедрение: может потребоваться настройка и обслуживание сервера Keycloak.

**Собственное решение**:
- **Преимущества**:
  - Полный контроль: вы можете настроить всё именно так, как вам нужно, от структуры БД до API.
  - Гибкость: возможность интегрироваться с другими системами на специфических условиях.

- **Недостатки**:
  - Время на разработку: потребуется значительно больше времени для разработки, тестирования и поддержки.
  - Безопасность: потребуются значительные усилия для правильной реализации безопасной аутентификации и авторизации.

**Рекомендация**: Используйте **Keycloak**, если вы хотите быстро внедрить некоторый функционал, который можно будет настраивать впоследствии. Если у вас есть очень специфические требования или вы хотите максимально контролировать решение, можно рассмотреть разработку собственного решения, но это займет больше времени.

### 2. Организация взаимодействия между сервисами

Для взаимодействия между сервисами (например, для получения списка исполнителей) можно реализовать следующую архитектуру:

- **HTTP-запросы с токенами**: Сервисы в вашей локальной сети могут интегрироваться через RESTful API с использованием токенов доступа (например, JWT).
- **Токены**: Каждый сервис будет владеть полученным токеном для авторизации у сервиса авторизации (Keycloak), чтобы получать список пользователей.
- **Контроль доступа**: Ограничьте доступ к API на уровне сервиса авторизации. Необходимо проверять, имеет ли пользователь необходимые права для извлечения данных (например, только пользователи с ролью «администратор» могут запрашивать информацию об исполнителях).
- **API Gateway**: Можно рассмотреть использование API Gateway для координации запросов и встроенной обработки авторизации.

**Безопасность**:
- Используйте HTTPS для шифрования всех запросов.
- Применяйте проверки токенов на уровне сервиса авторизации.

### 3. Статические токены и их недостатки

Статические токены без срока действия могут быть реализованы с использованием систем, таких как Redis. Однако у такого подхода есть несколько недостатков:

- **Отсутствие контроля над токенами**: Статические токены не могут быть отозваны (например, при выходе пользователя из системы или изменении его прав).
- **Риски безопасности**: Если статический токен будет скомпрометирован, злоумышленник будет иметь доступ на неопределенный срок (пока токен не будет заменен).
- **Нет поддержки механизма обновления**: При использовании JWT у вас есть возможность обновлять токены и устанавливать срок действия, что позволяет улучшить безопасность.
- **Упрощенная логика**: Нужен более сложный код для управления пользовательскими сессиями, чем с JWT.

**Рекомендация**: Используйте **JWT**, так как они обеспечивают лучшую безопасность и управляемость по сравнению со статическими токенами.

### Особенности стека

С учетом вашего стека разработки (Blazor WASM для пользовательского интерфейса и ASP.NET Core Web API для бэкенда), важно организовать безопасное взаимодействие между вашим UI и вашими сервисами через API с применением авторизации с использованием JWT или подходов Keycloak. При этом интерфейс с пользовательским опытом и API должны быть спроектированы так, чтобы минимизировать количество запросов и повысить общую производительность системы.