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

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

Здесь сценарий:

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

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

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

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

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

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

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

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

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

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

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

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

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

Джереми

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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