Это не явные перекрестные сессии домена, которые я ищу, но это самый простой способ объяснить, что я хочу.
У меня есть система, которая создает веб-сайты. Веб-сайты размещаются на разных серверах.
Пользователи могут создавать свою учетную запись, а затем создавать множество сайтов. Они могли бы создать
www.mysite.com subdomain.mysite.com и создавать множество разных сайтов.
Несколько раз сайты будут ПОЛНОСТЬЮ отличаться друг от друга, однако в некоторых случаях сайты фактически будут настолько тесно связаны, что их, вероятно, следует рассматривать как один и тот же сайт.
Например: (Разный домен полностью) mysite-news.com mysite-blog.com или (тот же домен, другой поддомен) news.mysite.com blog.mysite.com
Мне нужен способ для пользователей, где они хотят, создать федерацию сортировки, которая позволяет, щелкнув флажок, чтобы они разрешали вход в систему с несколькими сайтами. Я не могу изменять конфигурацию, если ее постоянное изменение и не повлияет на другие сайты, потому что пострадают 1000 сайтов.
Как вы считаете, лучший способ поддержать это? OpenID, SSO?
Мне нужно что-то, что просто для сайтов, чтобы создать «федерацию», а затем позволить своим входным знакам быть перекрестным доменом. Если кто-то хочет присоединиться, то они могут.
OpenID предоставляет несколько полезных функций, но, к сожалению, поведение кросс-домена, которое вы ищете, не является тем, что вы найдете в стандартной реализации OpenID. Одним из основных принципов разработки OpenID является то, что поставщик не раскрывает никакой информации о пользователе без их явного согласия *, и поэтому любой авторитетный поставщик OpenID никогда не расскажет mysite-news.com, что вы уже вошли в mysite-blog .com, не запрашивая одобрения пользователя.
[С технической точки зрения, здесь происходит то, что mysite-news.com и mysite-blog.com концептуально находятся в одной и той же области безопасности, но OpenID идентифицирует сферы по шаблонам URL-адресов, и поскольку они находятся в разных доменах, они не совпадают.]
И это не дает вам пользовательский интерфейс, который вам нужен. Есть некоторые предыдущие ответы, которые прекрасно справляются с описанием системы, в которой вы нуждаетесь:
Короче говоря, вы будете устанавливать какую-то службу auth на login.mysite.com для ответа на запросы с mysite-news.com и mysite-blog.com. Есть еще несколько способов, которыми вы можете воспользоваться OpenID в этом.
В потоке redirect-to-login-and-return-a-signed-token описано, что именно делает OpenID. Таким образом, вы все еще можете использовать реализацию OpenID для выполнения всех операций с подписанными токенами и защитой от повтора, ваши клиентские сайты просто пропустят первоначальную «открытую» часть OpenID и всегда перенаправляют пользователей к провайдеру login.mysite.com. И login.mysite.com позволяет пропустить шаг «доверять mysite-blog.com», потому что это специализированный провайдер, который может иметь свой собственный белый список сайтов, с которыми он всегда работает. OpenID был бы исключительно за кадром, пользователи никогда не узнают, что OpenID каким-то образом задействован.
login.mysite.com может, в свою очередь, использовать OpenID, чтобы попросить пользователей пройти аутентификацию против своего провайдера OpenID (будь то Google или Yahoo или специалист, такой как myOpenID). Оттуда он будет выглядеть как стандартный идентификатор OpenID, и вы получите все преимущества, недостатком является то, что ваша цепочка переадресации входа становится немного длиннее (и, соответственно, медленнее). Их перерывы.
Удачи. Это вопрос, который возникает довольно часто, и мне еще предстоит найти действительно отличную ссылочную реализацию, на которую я могу указать людей, поэтому, если вы найдете что-то хорошее, вернитесь и сообщите нам об этом.
Наконец, обязательная ссылка на сценарий Матасано Чардэна по этому вопросу .
[*] недавнее фиаско Google Buzz – хорошее напоминание о том, что происходит, когда вы удивляете пользователей тем, с кем их общая информация.
SSO – это просто концепция / состояние … Это то, чего вы пытаетесь достичь.
OpenID хорош для аутентификации, и он хорош для аутентификации с нескольких сайтов. Он не переносит информацию аутентификации с одного сайта на другой.
Что, по-видимому, является отраслевым стандартом SSO-технологии IMO, является OAuth. Он используется Facebook, Twitter, Google и т. Д.
Google реализовал гибридный протокол OpenID и oAuth, который они пытаются использовать в качестве стандартного метода проверки подлинности. Google предоставляет интегрированное решение для входа почти так же, как вы упомянули.
Из моего толкования в отношении того, о чем вы упоминали, вы имеете в виду решение, которое пользователь может просто установить флажок в своих настройках, чтобы подписываться везде, где поддерживается их учетная запись … Это противоречит принципам как oAuth, так и OpenID. Я не знаю о текущем решении, которое на самом деле стоит чего-то.
В основном, что делается сейчас, вместо того, чтобы подключаться к каждому сайту по отдельности с помощью единого входа, предоставленного OpenID … Вы входите на сайт с вашей учетной записью OpenID, вы перенаправляетесь на запрос авторизации oAuth. Затем это позволит серверу oAuth аутентифицировать вас на этом сайте в будущем до тех пор, пока разрешение не будет отозвано до тех пор, пока вы аутентифицируете свою учетную запись OpenID с помощью этой службы oAuth.
Как вы полагаете, подходит либо openId, либо SSO.
См. Мой пост 29 июля 2008 года, 12:50 в http://groups.google.co.uk/group/comp.lang.php/browse_thread/thread/b682ed2a8b7fbb3f/f5f27f120e264fa0?hl=ru&lnk=gst&q=single+sign+ на + symcbean # f5f27f120e264fa0
для примера того, как реализовать SSO.
C.
Как объяснил @кетурн, OpenID не позволяет неявное доверие, не обманывая систему, поэтому я бы не рекомендовал ее для этой конкретной проблемы. Вместо этого я бы посмотрел на Shibboleth – Single-Sign-On, предназначенный для децентрализованной архитектуры.
Предположим, что сайт master.example.com связан с веб-сайтом child.example.com , так что master.example.com предоставляет функции входа для child.example.com . Пользователь с зарегистрированным входом на master.example.com теперь хотел бы получить доступ к ресурсу http://child.example.com/resource , который является только членом. Теперь, Шиболет пинает:
Реализации Shibboleth доступны для многих служб, таких как apache2 или на уровне приложений, как в php (например, SimpleSAML ).