Единый вход по нескольким системам, включая сторонние системы

Question

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

В этом примере пользователь купил бы продукт и зарегистрировался на нашем сайте. Эти данные содержатся в нашей базе данных.

В конце транзакции пользователю предоставляется возможность отправки с использованием вспомогательного обслуживания, предоставляемого третьим лицом. Они входят в систему/регистрируются в третьей стороне, а сторонняя организация хранит все свои данные.

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

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

Есть ли разумный способ подойти к этой проблеме? Каковы плюсы и минусы?

EDIT

The post by APICrazy, кажется приемлемым, хотя это потребовало бы стороннего поставщика для интеграции с брокером аутентификации и предоставить нам в качестве одного из поставщиков удостоверений.

Был ли способ преодолеть это, если у вас нет сторонних изменений, но вы все равно принимаете учетные данные из нашего хранилища имен?

Answer 1

Вопрос, который вы поставили, очень широк. Если бы я подвел итоги, ваша организация начнет проект Identity and Access Management (IAM), который будет сосредоточен на федерации/SSO и обеспечении пользователей. Ваши клиенты будут выполнять SSO на сервере Identity Provider (IdP), либо напрямую с учетными данными, хранящимися в вашем хранилище учетных данных пользователя (AD/LDAP/etc), либо через соединитель идентификации облака (Facebook/LinkedIn/etc). После аутентификации на вашем портале междоменная федерация с сторонними веб-сайтами выполняется через стандарты идентификации, такие как SAML, OAuth, OpenID Connect. Стандарт SCIM также будет полезен, так как вы, вероятно, столкнетесь с необходимостью предоставления пользователей через сторонние веб-сайты.

В этом пространстве существует ряд решений для поставщиков, которые могут решить ваши варианты использования выше. Я бы посмотрел на поставщиков, которые поддерживают широкий набор вариантов использования и стандартов федерации. Мою рекомендацию мы должны проконсультироваться с экспертом с системами IAM, here is a good article that describes IAM Architecture Approach. Другая рекомендация - взглянуть на некоторых из самых высоко оцененных поставщиков Gartner, в основном Okta, OneLogin, Ping Identity, Microsoft и Centrify. Вам нужно будет определить, должна ли облачная среда обладать или быть на месте. Основываясь на вашем широком описании требований, на месте (который может управляться на экземпляре AWS) может быть лучше, поскольку облачные возможности, как правило, ограничены для использования в прецедентах.