MyOpenID в ACS: добавление необходимых типов заявок

Этот вопрос является продолжением раздела Как передать необходимые утверждения поставщику удостоверений OpenID с помощью Azure ACS?

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

примеры Azure ACS показывают, что можно добавить произвольное удостоверение OpenID. провайдеры для ACS. Но для того, чтобы ACS действительно была полезна в нашем проекте в качестве STS для различных популярных провайдеров, мы решили заставить ACS работать с MyOpenID.com (опять же, также используется в примерах). Проблема, а также хорошее доказательство Vittorio заключается в том, что MyOpenID не будет предоставлять нам утверждения, такие как имя и адрес электронной почты, если их не попросят. Витторио и другие утверждают, что это связано с тем, что MyOpenID не поддерживает обмен атрибутами.

Хотя я в этом не уверен. Копнув немного глубже URL-адрес запроса, который генерирует ACS, я вижу такие параметры, как openid.ns.ax=http://openid.net/srv/ax/1.0 и openid.ax.required=email,fullname,firstname,lastname. Кроме того, openid.ax.type.email относится к типу axschema.org/contact/email. Вот где что-то идет не так с MyOpenID. MyOpenID не понимает типы axschema.org и поэтому не возвращает значение электронной почты.

Что я знаю, так это то, что MyOpenID понимает тип schema.openid.net/contact/email. Поэтому, основываясь на этом, я вручную изменил URL-адрес запроса ACS, чтобы использовать схему openid.net вместо схемы ax. О чудо, MyOpenID реагирует и показывает, что мой адрес электронной почты действительно будет возвращен.

Вот список параметров, которые я пытаюсь передать в конечную точку myopenid.com/server:

К сожалению, когда ответ возвращается обратно в ACS, он недостаточно хорош, и ACS завершается с ошибкой со следующими кодами:

Код ошибки HTTP: 400 Сообщение: ACS30000: произошла ошибка при обработке ответа на вход OpenID. Внутреннее сообщение: ACS90014: отсутствует обязательное поле «openid.ax.value.email». Идентификатор трассировки: f8e09e6f-0765-4370-9f03-f744cce6fa2a Отметка времени: 2011-08-02 17:12:57Z

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

Вопрос в следующем: кажутся ли вам параметры моего запроса правильными или я упустил что-то очевидное?

ПРИМЕЧАНИЕ. моя первоначальная настройка работает. Если я оставлю запрос ACS без изменений и в ACS настрою только одно правило транзита для поставщика удостоверений, я смогу успешно аутентифицировать свой веб-сайт через ACS, используя поставщика удостоверений MyOpenID. Проблема остается, хотя MyOpenID не будет передавать, например. Полное имя или электронная почта для ACS, если запрос от ACS явно не запрашивает типы утверждений http://schema.openid.net/namePerson или http://schema.openid.net/contact/email.


person Peter Lillevold    schedule 04.08.2011    source источник


Ответы (1)


Из соображений безопасности ACS не может разрешить вызывающим абонентам повторно вводить заявку на адрес электронной почты. По сути, то, что вы делаете по незнанию, является попыткой атаки 4.5 (путаница типов данных OpenID) из эта статья. Из соображений безопасности служба ACS должна убедиться, что адрес электронной почты и другие утверждения AX, которые она поддерживает, точно соответствуют типам, о которых она знает, иначе злоумышленники могут обмануть ACS и заменить одно утверждение другим. Дело не в том, что ACS не поддерживает AX, а в том, что ACS поддерживает только один тип утверждения в качестве утверждения электронной почты, и это не то же самое, что использует MyOpenID. Короче, это не сработает.

person Oren Melzer    schedule 10.04.2012
comment
Как злоумышленники могут заменить одно утверждение другим? В ACS должно быть установлено правило для преобразования входящей заявки в выходную заявку. Таким образом, через ACS к конечному пользователю будут передаваться только ожидаемые типы заявок от доверенных IDP. - person Peter Lillevold; 10.04.2012
comment
И заметьте: я не хочу, чтобы это делалось вне ACS, я хочу иметь возможность настраивать этот внутри ACS. Весь эксперимент по повторному вводу типов утверждений предназначен только для того, чтобы доказать, что IDP, такие как myOpenID, действительно могут правильно отвечать на действительные запросы AX. - person Peter Lillevold; 10.04.2012
comment
В своем стремлении ответить я забыл сказать спасибо за участие :) ... но, как вы сказали, поддерживает только один тип запроса электронной почты: вот почему я думаю, что в ACS есть искусственное ограничение. Мой общий вопрос: почему ACS заботится? Превосходный механизм правил в ACS уже готов, чтобы мы могли преобразовывать различные типы заявок по мере их поступления от Idp. Мне кажется, что единственной недостающей частью является возможность настроить ACS для запроса различных типов заявок (включая типы электронной почты) и включить их в конвейер правил. - person Peter Lillevold; 11.04.2012