Как определить поставщика OpenID как требующего направленной идентификации? - PullRequest
Новая
       4

Как определить поставщика OpenID как требующего направленной идентификации?

2 голосов
/ 13 июня 2010

Я пытаюсь расширить библиотеку PHP LightOpenID , чтобы "обнаружить", что провайдеру идентификации требуется Направленная идентификация.Это должно быть легко, так как библиотека прекрасно написана и чудесно чиста, но я не знаю, как определить таких поставщиков.Я попробовал пару вещей:

  • Я просмотрел спецификации OpenID по теме, но пришел с пустыми руками.
  • Просматривал PHP OpenID библиотека, но не смог выяснить, как эта информация была собрана во время обнаружения.
  • Извлекла все данные (заголовки и контент), которые пришли с серверов, введя некоторый код в LightOpenID, но не 'ничего полезного.
  • Естественно, что Google и Stackoverflow искали.

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

Кто-нибудь знает, где я могу найти больше об этом?

1 Ответ

5 голосов
/ 13 июня 2010

РЕДАКТИРОВАТЬ : выше описан механизм выбора идентификатора . Хотя направленный идентификатор требует идентификатор выбора и иногда действительно используется для ссылки на идентификатор выбора , эти два термина различны. См. эту статью . Направленная личность не может быть обнаружена.

A направленный идентификатор - это непрозрачный идентификатор, уникальный для данного сайта. Один и тот же URL-адрес OpenID постоянно возвращается на определенный сайт-потребитель, но ни одному из двух сайтов-потребителей никогда не предоставляется один и тот же URL-адрес OpenID для пользователя. Направленная личность защищает от сговора.

ORIGINAL

Я не понимаю, почему вы указали ссылку "5.1. Прямая связь" в спецификации OpenID. Насколько я понимаю, «направленная идентификация» - это когда провайдер OpenID направляет пользователя посредством выбора идентификатора, который он может использовать для идентификации себя (см. здесь в разделе «Направленная идентификация»).

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

https://www.google.com/accounts/o8/id

и затем Google генерирует анонимный идентификатор, специфичный для OP, например

www.google.com/accounts/o8/id?id=aitodwer

, который является фактически заявленным идентификатором.

Поставщик OpenID не «требует» направленной идентификации, но может не поддерживать ее. Что определяет, будет ли использоваться направленная идентификация или нет, так это то, вводит ли пользователь идентификатор, который, как он утверждает, принадлежит ему, или вводит URL-адрес поставщика. Хотя провайдер может не поддерживать направленную идентификацию, он всегда поддерживает ненаправленный вид, даже если, как в случае с Google, вы не можете априори знать, каким будет ваш заявленный идентификатор (Google генерирует его для каждой ретранслирующей стороны). Это связано с тем, что ретранслирующая сторона должна иметь возможность выполнить обнаружение заявленного идентификатора (и, возможно, выполнить прямую проверку, если ретранслирующая сторона не имеет статуса). ( ну, технически возможно, что провайдер запретит запросы на аутентификацию без identifier_select, но я не думаю, что кто-то делает это )

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

  • URL-адрес конечной точки поставщика и только версия протокола («Направленный идентификатор»). В этом случае ретранслирующая сторона будет использовать специальное значение http://specs.openid.net/auth/2.0/identifier_select в качестве как заявленного, так и локального идентификатора OP.
  • URL-адрес конечной точки провайдера, версия протокола, заявленный идентификатор (идентификатор, предоставленный пользователем) и локальный идентификатор OP (локальный идентификатор OP - это идентификатор, относящийся к определенной конечной точке - например, я мог бы установить на сайте www.mydomain.com, что привело к обнаружению нескольких провайдеров OpenID, каждый из которых имеет свой локальный идентификатор OP)

Вот как XML будет выглядеть в обоих случаях:

Направленный идентификатор (пример из Google - обратите внимание на отсутствие элемента LocalId) 

<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
    <XRD>
        <Service priority="0">
            <Type>http://specs.openid.net/auth/2.0/server</Type>
            <Type>http://openid.net/srv/ax/1.0</Type>
            <Type>http://specs.openid.net/extensions/ui/1.0/mode/popup</Type>
            <Type>http://specs.openid.net/extensions/ui/1.0/icon</Type>
            <Type>http://specs.openid.net/extensions/pape/1.0</Type>
            <URI>https://www.google.com/accounts/o8/ud</URI>
        </Service>
    </XRD>
</xrds:XRDS>

Ненаправленная личность (пример из спецификации) 

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/auth/2.0/signon</Type>
  <URI>https://www.exampleprovider.com/endpoint/</URI>
  <LocalID>https://exampleuser.exampleprovider.com/</LocalID>
</Service>

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

...