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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Джереми


person Jeremy Goodell    schedule 02.04.2010    source источник
comment
Мне любопытно, почему кто-то вчера проголосовал за этот вопрос. Хотите прокомментировать?   -  person Jeremy Goodell    schedule 26.05.2012
comment
Обратите внимание, что спустя ДВА ГОДА после публикации кто-то проголосовал за него. По совпадению (возможно?), человек, который проголосовал против, мог быть тысячным зрителем.   -  person Jeremy Goodell    schedule 26.05.2012
comment
Я ищу что-то очень похожее. Вы нашли решение своей проблемы? Пожалуйста, поделитесь любыми идеями о том, как это сделать.   -  person Gala101    schedule 26.07.2013
comment
@ Gala101 Извините, не совсем. В итоге я ушел из компании, где должен был выполнять эту задачу, так что это больше не было для меня приоритетом.   -  person Jeremy Goodell    schedule 26.07.2013
comment
Этот вопрос очень похож на stackoverflow.com/ вопросов/4664178/ и stackoverflow.com/questions/8934753/   -  person Simon East    schedule 16.07.2015


Ответы (2)


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

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

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

person John    schedule 02.04.2010

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

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

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

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

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

person Bob    schedule 03.04.2010