#oauth-2.0 #single-sign-on #saml
#oauth-2.0 #единый вход #saml
Вопрос:
Я на стадии проектирования, поэтому открыт для предложений (даже язык или фреймворк открыты JAVA / NodeJS / Python Spring / Express / Django и т. Д.)
Мои требования — иметь мультирегиональное развертывание системы, где каждый регион имеет свою собственную базу данных и, возможно, свою собственную версию. Мне нужен один домен, куда пользователь будет заходить и перенаправляться в соответствующий регион, и даже тогда некоторые учетные записи будут использовать SAML IDP клиента, а некоторые будут использовать наш собственный IDP.
С точки зрения пользователя я подумал о чем-то подобном: ему будет показана страница, на которой он вводит свой адрес электронной почты (без pw), при этом мы перенаправим его в нужный регион, там, если он является учетной записью SAML, он будет перенаправлен на страницу входа в saml компании, если нет,мы можем выполнить простой вход пользователя / pw на нашем IDP
в фоновом режиме у нас может быть служба аутентификации с таблицей поиска в каждом регионе, база данных будет реплицироваться по регионам, когда пользователь переходит к app.acme.com или он будет перенаправлен в службу аутентификации в ближайшем географическом регионе служба аутентификации предоставит ему первую страницу входа в систему где он войдет в isэлектронная почта, служба аутентификации просмотрит электронное письмо (по домену) и перенаправит на нужные службы аутентификации (при необходимости), там служба узнает, является ли он SAML или нет, и перенаправит соответствующим образом
Что касается последующих вызовов, либо URL-адрес изменится на app-us.acme.com и будет зависеть от конкретного региона. ИЛИ, может быть, сохранить файл cookie сеанса или что-то в этом роде, что поможет направить дальнейшие вызовы в нужный регион.
Я открыт для различных предложений и даже более открыт, если уже есть фреймворк, в котором это есть из коробки
Комментарии:
1. Каков план для BC / DR? Должны ли утверждения из IDPL использоваться в каждом регионе? Что требует регионального неравенства — A / B тестирование или синие / зеленые развертывания? Почему они не должны поддерживаться и в регионе?
2. Я не понимаю, как BC / DR имеет отношение к этому вопросу. Региональное неравенство необходимо, поскольку я собираюсь иметь дело с корпоративными компаниями по всему миру, В каждой стране свои правила, такие как GDPR для Европы и т. Д., А некоторые страны требуют, Чтобы их данные хранились в их собственном регионе и т. Д. Мне нужно иметь возможность поддерживать свой собственный IDP, но также поддерживать авторизацию в отношении IDP компаний моих клиентов, если они у них есть. Утверждения должны быть для каждой учетной записи, а учетная запись находится в одном конкретном регионе.
3. Требования к хранилищу PII не должны приводить к тому, что архитектура не сможет извлекать его по мере необходимости. GDPR требует суверенитета данных в состоянии покоя, а не суверенитета данных в процессе передачи. Вместо этого рассмотрите инструменты агрегирования данных, такие как виртуальный каталог или аналогичные, которые позволяют хранить базу пользователей на региональном уровне, но адресовать ее глобально. Таким образом, ваше приложение SAML может быть адресовано глобально, а приложение, которое вы разрабатываете, может иметь дело с регионализацией и i18n по мере необходимости.
4. во-первых, я бы не хотел размещать свои базы данных в виртуальном каталоге, проблемы с целостностью данных и т. Д. Во-вторых, хранилище PII является лишь частью причины, также существует необходимость разделения версий (EAP, разные SLA и т. Д.).
5. Похоже, у вас все спланировано. Удачи с вашей реализацией.