Единый выборочный вход для нескольких доменов - PullRequest
4 голосов
/ 14 февраля 2010

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

У меня есть система, которая создает сайты. Веб-сайты размещены на множестве разных серверов.

Пользователи могут создать свою учетную запись, а затем они могут создавать множество веб-сайтов. Они могли бы создать

www.mysite.com subdomain.mysite.com и создавать множество разных сайтов.

Иногда сайты будут ПОЛНОСТЬЮ отличаться друг от друга, однако иногда сайты будут настолько тесно связаны, что их, вероятно, следует будет рассматривать как один и тот же сайт.

Например: (Другой домен полностью) mysite-news.com mysite-blog.com или (тот же домен, другой поддомен) news.mysite.com blog.mysite.com

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

Как вы думаете, что будет лучшим способом поддержать это? OpenID, SSO?

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

Ответы [ 4 ]

12 голосов
/ 19 февраля 2010

OpenID предоставляет некоторые приятные функции, но, к сожалению, междоменное поведение, которое вы ищете, не то, что вы найдете в стандартной реализации OpenID. Один из основных принципов разработки OpenID заключается в том, что провайдер не раскрывает какую-либо информацию о пользователе без его явного согласия *, и поэтому любой уважаемый провайдер OpenID никогда не сообщит mysite-news.com, что вы уже вошли в mysite-blog. .com без запроса подтверждения пользователя.

[С технической точки зрения, здесь происходит то, что mysite-news.com и mysite-blog.com концептуально находятся в одной и той же «области безопасности», но OpenID идентифицирует области по шаблонам URL, и, поскольку они включены разные домены они не совпадают.]

И это не дает вам того опыта, который вам нужен. Есть несколько предыдущих ответов, которые отлично описывают тип системы, которая вам нужна:

Короче говоря, вы будете настраивать своего рода службу аутентификации на login.mysite.com для ответа на запросы от mysite-news.com и mysite-blog.com. Есть еще несколько способов, которыми вы можете воспользоваться OpenID в этом.

  1. Описанный поток перенаправления на вход в систему и возврат подписанного токена - именно то, что делает OpenID. Таким образом, вы по-прежнему можете использовать реализацию OpenID для управления всеми подписанными токенами и защиты воспроизведения: ваши клиентские сайты просто пропускают начальную часть «обнаружения» OpenID и всегда перенаправляют пользователей к поставщику login.mysite.com. И login.mysite.com пропускает шаг «доверяю ли я mysite-blog.com», потому что это провайдер специального назначения, у которого может быть свой собственный белый список сайтов, с которым он всегда работает. OpenID был бы здесь просто закулисным, пользователи никогда бы не узнали, что OpenID каким-то образом был вовлечен.

  2. login.mysite.com, в свою очередь, может использовать OpenID, чтобы попросить пользователей пройти аутентификацию на своем провайдере OpenID (будь то Google или Yahoo или такой специалист, как myOpenID). Оттуда это будет выглядеть как стандартный вход в OpenID, и вы получите все преимущества, недостатком является то, что ваша цепочка перенаправления входа становится немного длиннее (и соответственно медленнее). Это перерывы.

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

Наконец, обязательная ссылка на сценарий Матасано Чаргена по теме .

[*] недавнее фиаско в Google Buzz - хорошее напоминание о том, что происходит, когда вы удивляете пользователей тем, с кем обмениваются их информацией.

3 голосов
/ 24 августа 2011

Единый вход - это просто концепция / состояние ... Это то, чего вы пытаетесь достичь.

OpenID хорош для аутентификации, и это хорошо для аутентификации с нескольких сайтов. Он не переносит информацию аутентификации с одного сайта на другой.

То, что кажется отраслевым стандартом технологии SSO IMO - это oAuth. Он используется Facebook, Twitter, Google и т. Д. *

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

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

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

2 голосов
/ 23 августа 2011

Как объяснил @keturn, OpenID не допускает неявного доверия, не обманывая систему, поэтому я бы не рекомендовал его для этой конкретной проблемы. Вместо этого я бы взглянул на Shibboleth - единый вход, предназначенный для децентрализованной архитектуры.

Предположим, что веб-сайт master.example.com связан с веб-сайтом child.example.com , поэтому master.example.com обеспечивает вход в систему функциональность для child.example.com . Пользователь с зарегистрированным логином на master.example.com теперь хочет получить доступ к ресурсу http://child.example.com/resource,, который доступен только для членов. Шиболет начинает:

  1. Аутентификация: есть ли у пользователя токен безопасности?
    1. Если у пользователя уже есть токен безопасности от master.example.com , он проверяется на действительность и процесс продолжается на шаге 2.
    2. Если у пользователя нет действующего токена, он перенаправляется на сайт входа, например http://master.example.com/login. После входа пользователь перенаправляется на шаг 1.
  2. Авторизация (необязательно): master.example.com может разрешить или запретить доступ к определенному ресурсу на child.example.com , предоставив дополнительную информацию (например, конкретный форум на child.example.com доступен только для премиум-членов master.example.com . Информация о статусе пользователя пользователя видна только master.example. com , поэтому он должен разрешить или запретить доступ).

Shibboleth Реализации доступны во многих сервисах, таких как apache2 или на уровне приложения, как в php (например, SimpleSAML ).

2 голосов
/ 15 февраля 2010

Как вы предлагаете, подойдет либо openId, либо SSO.

Смотрите мой пост 29 июля 2008 г., 12:50 в http://groups.google.co.uk/group/comp.lang.php/browse_thread/thread/b682ed2a8b7fbb3f/f5f27f120e264fa0?hl=en&lnk=gst&q=single+sign+on+symcbean#f5f27f120e264fa0

для примера того, как реализовать SSO.

С

...