Использование OpenID в качестве логина для моего веб-сайта — избыточные провайдеры

Как обеспечить избыточность на моем веб-сайте входа с OpenID?

Например, у меня есть пользователи, которые требуют 100% безотказной работы (да, верно, но давайте подойдем как можно ближе).

Некоторые из них используют менее доступных провайдеров (например, myphpid на их собственном веб-сайте или идентификатор в стартапе, у которого частые простои). Теперь я могу перевести их к более надежному провайдеру, но я также хочу иметь некоторую избыточность.

Я надеюсь, что смогу развернуть одно решение, но недостаточно понимаю OpenID, чтобы попробовать:

Настройте несколько phpmyid на разных хостингах с одинаковыми учетными данными (хэш/ключ/и т. д.), но разными доменами (в идеале у меня был бы циклический DNS и одно и то же имя, но я также хочу учитывать случай, когда они имеют разные домены).

Будет ли это работать? Другими словами, у меня есть точно такие же файлы phpmyid, включая учетные данные, на разных серверах. Могу ли я использовать example.com/id и example2.com/id и ожидать, что они будут выглядеть одинаково на моем конце, чтобы мне не нужно было связывать несколько учетных записей OpenId с каждым пользователем в моей системе?

Пока я использую пример phpmyid, вопрос более общий - важны учетные данные или домен/ip/??? также связаны таким образом, чтобы предотвратить это?

Существует ли или может ли существовать стандарт, который позволял бы перемещать свой OpenID от одного провайдера к другому без необходимости отсоединения и повторной привязки на каждом веб-сайте, на котором они использовали этот openid?

-Адам


openid replication reliability login redundancy
person Community    schedule 24.09.2008    source источник

Ответы (2)


arrow_upward
2
arrow_downward

OpenID — это URL-адрес. example.com/id и example2.com/id — это два разных OpenID, независимо от того, какой провайдер их размещает или какими учетными данными пользователи делятся с этими провайдерами. Надежность OpenID действительно сводится к надежности хостинга этого URL. Да, вы можете определить резервных поставщиков в своем документе XRDS, но вы все равно должны быть в состоянии обнаружить этот документ по URL-адресу OpenID.

Таким образом, методы обеспечения надежности для OpenID по большей части такие же, как и для любого другого веб-ресурса с фиксированным URL-адресом. И, как полагающаяся сторона, вы мало что можете с этим поделать. Как вы сказали, ваши пользователи сами должны выбрать провайдера OpenID, который соответствует их собственным требованиям. Вы можете предложить своим пользователям узнать у своего поставщика OpenID, доступно ли соглашение об уровне обслуживания.

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

person keturn    schedule 24.09.2008

arrow_upward
0
arrow_downward

Недавно я опубликовал ответ на вопрос "Как мне использовать больше чем один OpenID?", что может решить ваши проблемы.

Профессиональный провайдер должен иметь избыточную услугу, которая обычно достигается за счет наличия балансировщика нагрузки перед двумя отдельными серверами, но пользователи должны размещать документ XRDS на собственном домене (или с использованием i-имени) со ссылками на разных провайдеров (для отката). цели)

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

person Troels Thomsen    schedule 24.09.2008