Платформа "1С:Предприятие" версии 8.3.7 и выше
23.08.2018
В платформе "1С:Предприятие 8" поддерживается стандарт аутентификации OpenID v2 (http://v8.1c.ru/overview/Term_000000799.htm), подробнее о стандарте: http://openid.net/specs/openid-authentication-2_0.html (на английском).
OP - OpenID Provider, провайдер OpenID.
RP - Relying Party, клиент OpenID (веб-расширение "1С:Предприятия").
Публикация - каталог веб-сервера, обработку любых обращений в который обслуживает расширение (wsisapi.dll или wsapXX.dll) и в который добавлен файл default.vrd.
Подробнее о терминологии OpenID см. в стандарте: http://openid.net/specs/openid-authentication-2_0.html#terminology
Подробно настройка веб-серверов и OpenID-аутентификации описана здесь.
Кратко:
1. На клиенте в файле default.vrd элемент
Копировать в буфер обмена<openid> <rely url="https://myserver.org/users-ib/e1cib/oid2op"/> </openid>
где users-ib - это каталог веб-сервера с публикацией OP. При обращении на этот адрес из браузера, вы получите XRDS-файл с именем oid2op, содержащий настройки провайдера OpenID.
Внимание! Настройки протокола, имени сервера и порта должны совпадать с теми, которые используются для обращения к OP в других местах.
2. На провайдере в файле default.vrd внутри элемента
Копировать в буфер обмена<openid>
<provider>
<lifetime>432000</lifetime>
</provider>
</openid>
где lifetime - время жизни признака аутентифицированности идентификатора в секундах. В нашем случае не является важным.
3. Цепочка сертификатов, которыми подписан сертификат веб-сервера, на котором размещена публикация OP, для версий ниже 8.3.8, должен быть добавлен в cacert.pem (см здесь), а начиная с 8.3.8, в хранилище доверенных корневых сертификатов ОС.
После этого, если для пользователя включена аутентификация OpenID, то при попытке аутентификации в информационной базе, RP будет произведено обращение к публикации OP, для входа с помощью OpenID-аутентификации.
Простейший способ добавить сертификат в файл cacert.pem - это сохранить сертификат в формате X.509 Base64-encoded с помощью браузера, и потом добавить содержимое получившегося файла к cacert.pem. Подробнее об экспорте сертификата из браузера читайте в документации к браузеру или вашей ОС.
Важно! В режиме совместимости с версией 8.3.7 в качестве хранилища сертификатов используется файл cacert.pem.
Наиболее частое проявление проблемы с конфигурацией OpenID-аутентификации заключается в том, что после настройки по приведенной инструкции пользователь вместо окна аутентификации OpenID видит окно аутентификации локальной информационной базы. Стоит отметить, что для тонкого клиента окна различаются не очень сильно и одним из явных отличий локальной аутентификации является список выбора (combobox control) имен пользователя вместо обычного поля ввода для OpenID-аутентификации. Для веб-клиента всегда можно посмотреть на строку адреса браузера, в которой, при корректной работе OpenID, вместо адреса и пути к публикации клиентской информационной базой (RP), будет адрес и путь к публикации OP.
Ниже приводятся методы локализации и устранения проблемы. Список не является точной последовательностью действий, которую необходимо выполнить, а представляет собой действия, которые в комплексе помогают выявить возможную причину проблемы.
Во всех приведенных примерах используется стандартный порт HTTPS, при использовании других портов, указывайте их. Также используются следующие обозначения:
Для этого следует добавить в logcfg.xml указанные строки внутри элемента <config> :
Копировать в буфер обмена<system level="trace" class="OID2Log"/>
внутри элемента<log> также следует добавить :
Копировать в буфер обмена<event> <eq property="name" value="SYSTEM"/> </event>
Подробнее о настройках технологического журнала см. в документации.
Далее запустить клиента и после получения окна аутентификации изучить созданные им логи. Следует фильтровать события class=OID2Log. Часто по логам видно, что клиент OpenID не может соединиться с сервером:
Копировать в буфер обмена.... OP discovery error /openID/e1cib/oid2op
это означает следующее:
а) с клиента недоступна публикация OP по HTTPS (смотри пункт о проверке сетевой доступности ниже).
b) цепочка сертификатов, которыми подписан HTTPS-сертификат сайта, на котором опубликован провайдер, не прошла проверку (смотри пункт о проверке сертификатов OP)
Рекомендуется проверить сетевую доступность сервера, выполнив команду:
Копировать в буфер обменаtelnet OP_NAME https
В случае доступности, соединение должно быть установлено. В случае ошибки необходимо обращаться к сетевым администраторам.
Зайти браузером с машины с опубликованным клиентом OpenID, на провайдер OpenID:
https://OP_NAME/OP_IB_PUB/e1cib/oid2op
и проверить доступен ли адрес (должен скачиваться XRDP файл oid2op c настройками провайдера). Будте внимательны с адресом, который вы используете для проверки, лучше всего скопировать его из default.vrd публикации RP.
В случае, если файл не скачивается, необходима проверка сетевой доступности сервера OP. Так же браузер может выдать предупреждение о неверном сертификате веб сервера, подробнее смотри проверку сертификатов.
Убедитесь, что сертификат OP признается клиентом, как прошедший валидацию. Это означает, что:
Для этого откройте с компьютера с RP публикацию OP по HTTPS в браузере и посмотрите на используемый ими сертификат. Попробуйте разные браузеры, если у вас их больше одного. По ссылке ниже должно открываться окно локального логина в информационной базе OP.
https://OP_NAME/OP_IB_PUB
Современные браузеры обычно показывают цветом состояние проверки сертификатов для HTTPS-соединения и позволяют просмотреть информацию о сертификатах для соединения при щелчке на информационную иконку. Подробнее о цепочках сертификатов и их проверке, можно прочитать в руководстве к ОС или браузеру.
Помните, что прохождение валидации сертификатом в браузере, в версиях платформы "1С:Предприятие" младше 8.3.8, не означает, что они пройдут валидацию на клиенте "1С:Предприятия"! Проверьте наличие необходимых сертификатов в cacert.pem.
Проверьте настройки прокси общие для ОС и файл inetcfg.xml для платформы (см здесь). Необходимо убедиться, что если приведенные в данном описании проверки работают в браузере, но клиент "Предприятия" по-прежнему не работает, то нет отличий между конфигурацией прокси для вашего браузера и для клиента "Предприятия". По возможности для проверки уберите все прокси. Если это невозможно, проверьте, что они не изменяют HTTPS-траффик путем его дешифрации.
Если по пути от клиента к серверу установлено дешифрующее прокси, то вы сможете увидеть в браузере, что цепочка сертификатов выглядит по-другому. Обычно в ней вместо сертификата подписывающего сертификат сайта с публикацией OP, присутствует сертификат прокси. В этом случае добавлять в доверенные сертификаты нужно именно эту цепочку удостоверяющих сертификатов. Клиенты, проходящие через разные цепочки дешифрующих прокси или вообще не проходящие через них, будут видеть разные цепочки удостоверяющих сертификатов.
Общее правило состоит в том, что на конкретном клиенте сертификат сервера должен быть доверенным с учетом той цепочки сертификатов, как она выглядит с клиента. Т.е. необходимо открыть сертификат сервера с публикацией OP, например, в браузере и проверить, что он является доверенным. Другими словами, при наличии дешифрующего прокси добавлять в качестве доверенного нужно именно сертификат этого прокси, т.к. клиент будет устанавливать защищенное соединение именно с ним.
Для защиты от перенаправлений на потенциально опасные сайты, начиная с версии 8.3.8, в публикацию OpenID-провайдера добавлен новый элемент returnto. Элемент является необязательным, может не присутствовать или использоваться несколько раз. Содержимое элемента представляет собой регулярное выражение, которое определяет маску разрешенных имен хоста, на который будет производиться возврат (редирект) пользовательского браузера после исполнения команды openid (подробнее см. в документации).
Пример:
Копировать в буфер обмена<openid>
<provider>
<lifetime>604800</lifetime>
<returnto>mysite\.com</returnto>
<returnto>.*\.1c\.ru</returnto>
</provider>
</openid>
По умолчанию, из соображений безопасности в публикации элементы returnto отсутствуют.
Для обеспечения безопасности производится проверка соответствия полного имени пользователя выданного OP и URL сервера OP его выдавшего. Проверка производиться по совпадению протокола, имени и порта сервера указанного в публикации vrd. Параметр openid.identity передается в форме ответа OP к RP на адрес /e1cib/oid2rp. Перехватить ответы можно с помощью прокси, например fiddler. В случае не совпадения в ТЖ логируется ошибка следующего вида:
Копировать в буфер обмена39:50.223007-0,EXCP,... Rely Party: id_res invalid local id'
Например подобная настройка НЕ КОРРЕКТНА (не совпадает порт):
Копировать в буфер обменаidentity: https://server.ru:443/openid/e1cib/oid2op?lid=%D0...
op url: https://server.ru/openid/
Если все же ничего не помогает, то при обращении в поддержку желательно предоставить:
Перед отправкой, необходимо учитывать, что в конфигурациях и логах могут быть сохранены персональные данные, и оценить возможность их передачи!