Единый вход для веб-приложения

Question

Я пытался понять, как эта проблема решается уже больше месяца. Мне действительно нужно придумать общий подход к этой работе. У меня есть теория, но я просто не уверен, что это самый простой (или правильный) подход, и мне не удалось найти какую-либо информацию в поддержку моих идей.

Вот сценарий:

1) У вас есть сложное веб-приложение, которое предлагает защищенный контент по подписке.

2) Пользователи должны войти в приложение с именем пользователя и паролем.

3) Вы продаете крупным корпорациям, которые уже используют технологию корпоративной аутентификации (например, Active Directory).

4) Вы хотели бы интегрироваться с механизмом корпоративной аутентификации, чтобы их пользователи могли входить в ваше веб-приложение без ввода имени пользователя и пароля.

Теперь любое решение, которое вы придумаете, должно будет обеспечить механизм для:

• добавление новых пользователей
• удаление пользователей
• изменение информации о пользователе
• разрешение пользователям войти в систему

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

Теперь у меня есть теория, что способ сделать это (по крайней мере, для Active Directory) будет для меня написать клиентское приложение, которое интегрируется с Active Directory клиента для отслеживания целевых изменений, а затем сообщить о них изменения в моем веб-приложении. Я думаю, что если бы эта связь осуществлялась через веб-сервисы, предлагаемые моим веб-приложением, то это обеспечило бы непревзойденный уровень безопасности, что, очевидно, было бы требованием для этих корпоративных клиентов.

Я нашел некоторую информацию о продукте Microsoft под названием Служба федерации Active Directory (ADFS), который может или не может быть правильным подходом для меня. Он кажется немного громоздким и имеет некоторые требования, которые могут работать не для всех клиентов.

Для других существующих сценариев идентификации (таких как Афины и Шибболет) я не думаю, что клиентское приложение необходимо. Вероятно, это просто вопрос привязки к существующим службам идентификации.

Буду признателен за любой совет, который кто-нибудь даст по всем, что я здесь упомянул В частности, если вы можете сказать мне, верна ли моя теория о предоставлении клиентского приложения, которое взаимодействует с серверными веб-службами, или я полностью иду в неверном направлении. Кроме того, если бы вы могли указать мне на какие-либо веб-сайты или статьи, которые объясняют, как это сделать, я был бы очень признателен. Мое исследование пока что мало чем показалось.

Наконец, если бы вы могли сообщить мне о любых веб-приложениях, которые в настоящее время предлагают эту услугу (особенно связанных с корпоративной Active Directory), я был бы очень признателен. Мне интересно, предлагают ли другие веб-приложения B2B, например, salesforce.com или hoovers.com, аналогичные услуги для своих корпоративных клиентов.

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

Джереми

Answer 1

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

Мне трудно поверить, что многие компании открыли бы вам свою систему корпоративной аутентификации, просто чтобы предоставить SSO.

Возможно, вам будет удобнее использовать OpenID или аналогичный, а также использовать файл cookie "запомнить меня", чтобы уменьшить необходимость ввода паролей пользователями.

Answer 2

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

Отсюда и широкое внедрение OpenAthens и Shibboleth в сообществе академических библиотек для использования использования локально выданных учетных данных. Типичный средний / большой университет может подписаться на различные продукты / услуги от более чем пятидесяти различных издателей, и, развертывая OpenAthens / Shibboleth, они могут воспользоваться преимуществами открытого стандарта SAML (SAML - это протокол, который использует Shibboleth), который получает все более широкое распространение. не только в академическом секторе, но и в коммерческом секторе.

Ответ Джона, приведенный выше, указывает на еще одну проблему: существует ряд открытых стандартов, среди которых SAML и OpenID. Таким образом, поставщики контента должны решить, хотят ли они реализовать некоторые или все из них изначально, но они используют отдельные технологические стеки, и поэтому затраты на внедрение и поддержку могут быть дублированы.

Многие крупные издатели внедрили OpenAthens , поскольку это поддерживает Афины, SAML / Shibboleth и OpenID на одной платформе, с возможностью подключения других технологий или написания пользовательского модуля для внутреннего приложение для подключения, например учетная запись или система регистрации прав, в которую входят клиенты клиентов.

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