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

Question

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

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

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

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

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

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

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

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

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

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

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

Для других существующих сценариев ID (например, Athens и Shibboleth), я не думаю, что клиентское приложение необходимо. Вероятно, это всего лишь вопрос привязки к существующим службам ID.

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

И, наконец, если вы можете сообщить мне о любых веб-приложениях, которые в настоящее время предлагают эту услугу (особенно в связи с корпоративной Active Directory), я был бы очень благодарен. Мне интересно, если другие веб-приложения в Интернете, такие как 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 на одной платформе, с возможностью подключения других технологий или создания пользовательского модуля, позволяющего подключать внутреннее приложение, например. выставляли или систему Entitlements записи, которые пользователи клиентов регистрируетесь в.

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