1с apache аутентификация windows

Настройка веб-сервера Apache под Windows


План работ:

В отличие от IIS, веб-серверApaсhe доступен как для Windows, так и для Linux и позволяет настроить работу публикаций по шифрованному протоколу http.

1. Установка Apache под Windows

Первым делом необходимо скачать и установить веб-сервер. Список доступных реализаций можно найти по ссылке, а в статье будет использован самый первый из списка дистрибутивов. Он поставляется в виде zip-архива без инсталлятора.

Поэтому нужно скачать архив и разархивировать в любую удобную папку, например, C:\Apache24. 24. В названии папки указан номер версии Apache. В данном случае используется версия 2.4. При публикации информационной базы из командной строки стоит обращать на это внимание, так как с платформой поставляются отдельные библиотеки веб-компонент для версий Apache 2.2 и 2.4.

После разархивирования файла архива, откройте командую строку от имени администратора. Самый простой вариант – это открыть меню Пуск и ввести cmd. После того, как приложение будет найдено щелкнуть по нему правой кнопкой мыши и выбрать пункт меню «Запустить от имени Администратора» («Run as Administrator»).

В командной строке переходим в директорию распакованного Apache с помощью команды cd. Например:

В директории Apache вводим команду:

Это установит службу Apache, которой можно будет управлять в окне служб.

На этом установка Apache закончена. Осталось только опубликовать информационную базу и указать файлы сертификата в настройках Apache.

2. Выпуск самоподписанного сертификата Windows

В отличии от IIS, сертификат для Apache выпускается с помощью стороннего программного обеспечения OpenSSL.

По умолчанию в операционной системе Windows его нет. Поэтому его нужно скачать и установить самостоятельно. Возможные дистрибутивы OpenSSL для Windows указаны на wiki странице официального сайта.
В статье рассматривается дистрибутив по ссылке, который указан первым на странице wiki.

После скачивания дистрибутива установки необходимо его запустить.

На первой странице нужно согласиться с условиями лицензионного соглашения (переключить переключатель на «I accept the agreement») и нажать кнопку «Next».

Мастер переключится на страницу размещения дистрибутива. Если местоположение не планируется изменять, то можно оставить поле в значении по умолчанию и нажать кнопку «Next».

На следующем шаге ничего менять не нужно и можно просто нажать «Next».

Дистрибутив готов к установке. Нужно нажимать кнопку «Install» и дождаться завершения установки.

Финальный шаг – это страница пожертвований в пользу поддержки проекта. Если в планы не входит перечисление пожертвований, то необходимо снять все флажки и нажать кнопку Finish.

Дистрибутив OpenSSL установлен и теперь можно переходить к генерации сертификата.

Для этого необходимо запустить интерпретатор командной строки от имени Администратора.

Теперь нужно проверить, что исполняемый файл доступен из переменных окружения операционной системы. Нужно ввести openssl и если будет выведено сообщение, аналогичному на картинке, то воспользуйтесь инструкцией по добавлению директории bin в переменную окружения PATH.

Директория bin для OpenSSL была указана на втором шаге установщика.

Если пришлось добавить директорию bin в переменные окружения, то необходимо перезапустить командную строку от имени администратора. В противном случае, если ввод перешел в режим конфигурирования OpenSSL, нужно нажать сочетание клавиш Ctrl + C.

Далее нужно перейти в директорию Apache и создать папку, в которой будут располагаться файлы сертификатов.

После создания нужно перейти в созданную директорию.

После чего требуется ввести команду генерации сертификата, где вместо нужно подставить имя компьютера, на котором планируется размещен Apache:

3. Публикация информационной базы Windows

Перед публикацией базы нужно отредактировать в любом удобном редакторе файл, расположенный в директории дистрибутива Apache.

Нужно в файле найти секцию VirtualHost _default_:443 и в ней заменить SSLCertificateFile и SSLCertificateKeyFile на полные пути к ключу и закрытого файла сертификата, на подготовленные заранее файлы.

После этого можно переходить к публикации базы.

Для публикации информационной базы нужно открыть конфигуратор конкретной базы от имени администратора и перейти в пункт меню «Администрирование». После этого выбрать «Публикация информационной базы».

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

После этого требуется нажать кнопку «Опубликовать» и дождаться окончания операции.

4. Проверка публикации

Для проверки корректной работы нужно открыть страницу в браузере и перейти по ссылке, которая состоит из двух частей:

Для таких параметров ссылка будет иметь вид:

Источник

Настройка аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах


Описание проблемы

Не работает аутентификация операционной системы (windows) через IIS при использовании тонкого клиента или веб-клиента.

С точки зрения пользователей, будет видно окно с запросом логина и пароля.

Проблема может заключаться в том, что методы операционной системы в силу различных причин возвращают описание текущего пользователя сеанса в таком представлении, которое не совпадает ни с одним пользователем в списке пользователей информационной базы 1С

Решение проблемы

На сервере 1С включить технологический журнал, используя следующую настройку:

Воспроизвести ситуацию с неудачной аутентификацией операционной системы. Авторизоваться под пользователем операционной системы, указанным в свойствах пользователя 1С.

Открыть технологический журнал рабочего процесса и найти событие EXCP со следующим описанием: «Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя»

04:45.940011-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: SrcUserName1: svc-1c@DOMAIN701.COM
04:45.940012-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)
04:45.971001-0,CONN,2,process=rphost,t:clientID=60,Txt=Srvr: DstUserName2: DOMAIN701\testuser2(DOMAIN701\testuser2)
04:46.205021-0,EXCP,2,process=rphost,p:processName=trade,t:clientID=60,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=19,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

Заменить значение свойства «Пользователь» пользователя информационной базы согласно следующему формату «\\» + [Имя пользователя из свойства DstUserName2 без скобок].

Проверить работоспособность аутентификации средствами операционной системы, войдя в информационную базу, используя веб-клиент.

Читайте также:  Remmina for windows 10

Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах

В некоторых случаях, несмотря на корректно указанного пользователя операционной системы в пользователе информационной базы, при попытке входа в опубликованную базу через браузер аутентификация операционной системы не проходит. Такая ситуация может возникать, если веб-сервер IIS и сервер 1с находятся на разных машинах. В таком случае в технологическом журнале рабочего процесса можно наблюдать следующую картину:

56:39.487001-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: SrcUserName1: winserver1c$@DOMAIN701.COM
56:39.487002-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName1: testuser2@DOMAIN701.COM(DOMAIN701.COM\testuser2)
56:39.596004-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName2: NT AUTHORITY\ANONYMOUS LOGON(NT AUTHORITY\ANONYMOUS LOGON )
56:39.659003-0,EXCP,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):
a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

При возникновении такой ситуации необходимо проверить следующие настройки:

1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.

2) Убедиться, что веб-сервер IIS настроен корректно.

В публикации информационной базы найти настройки аутентификации

В настройках аутентификации отключить анонимную аутентификацию и включить Windows-аутентификацию. В Windows-аутентификации упорядочить доступных провайдеров так, чтобы на первом месте был Negotiate.

Пул приложений публикации не нуждается в настройках, в нем можно оставить все по умолчанию.

После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.

3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено «Доверять компьютеру делегирование любых служб (только Kerberos)»

Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение «Доверять компьютеру делегирование любых служб (только Kerberos)» и нажать применить.

4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.

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

Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования).

Источник

Все об AuthType или авторизация в Apache

Здесь я расскажу о возможностях Apache защищать содержимое сервера либо его частей.

Директивы Apache для контроля доступа

Если вам нужно просто разрешить или блокировать доступ к какой-либо части сайта или всему серверу в целом для определенных IP, используйте следующие директивы.

Значения: Order (allow,deny | deny,allow)

Директива Order указывает порядок, в котором будет производиться чтение из директив Allow и Deny

* Allow,deny — сначала читаются директивы Allow. Если пользователя нет в этом списке, то он блокируется. Если же он есть, то далее считываются директивы Deny(процесс еще не закончен). Если же пользователь есть и там, то он блокируется. Если его там нет, то он пропускается. Т.е пользователь пропускается только при наличии только в списке Allow, но не в Deny
* Deny,allow — сначала обрабатываются директивы Deny и отсеиваются те пользователи, которые есть в этом списке. Любые другие пропускаются. Т.е пользователь пропускается всегда, но если его нет в списке Deny

Формат директив: (Allow | Deny) from (IP | IPs | all) (IP | IPs | all) : (IP | IPs | all)

Директивы Allow и Deny определяют клиентов, которым разрешить или запретить доступ к серверу.

Директивы допускают использование:

* Одиночного IP(IP) — обычный вид IP, например, 127.0.0.1
* Группы IP(IPs) — группа IP, например, для доступа, только из локальной сети, 192.168.1.0/24
* Любого IP(all) — обозначает любой IP

После слова from может идти любое количество указанных директив, разделенных пробелом

В этом файле указывается доступ только для клиентов из локальной сети или с IP 11.11.11.12

Часть файла httpd.conf

Так мы баним сайт для какого-нибудь одного IP
Контроль по имени пользователя или группе

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

Значения: AuthType (Basic | Digest)

Apache поддерживает 2 типа защиты содержания (директива AuthType):

* Basic — базовая авторизация. Шифрование используется я на обеих сторонах, но клиент передает пароль не надежно зашифрованным, т. к не используется ключ шифрования. Это крупный недостаток этого метода. Применяется алгоритм шифрования Base64
* Digest — аутентификация специальным кодом (дайджестом), который использует ключ, конкретно, имя пользователя, пароль, область, требующая аутентификацию, различную информацию о запросе и уникальный код данного запроса, который Apache присваивает каждому соединению. Это однонаправленный метод, и для того, что бы расшифровать это, стороннему человеку требуется слишком много информации об обеих сторонах. Но главный недостаток этого метода в том, что его не поддерживает ни один пользовательский браузер, хотя сейчас это уже, наверное, не так (данные на 2000 год). Этот метод обычно используется в специализированных системах

Формат директивы: AuthName «String»

Эта директива указывает текст подсказки, которая отображается в браузере при входе на защищенную часть сайта, см. рисунок выше

Формат директив: (AuthUserFile | AuthGroupFile) «String»

Внимание! Для работы этих директив необходим модуль Apache mod_auth, который подключается по умолчанию

Эти директивы определяют, соответственно, путь (абсолютный) к файлу, хранящему связки Имя:DES и путь (тоже абсолютный) к файлу, хранящему связки Группа:Имя Имя : Имя

Содержит информацию о допустимых именах пользователей и их паролях в формате Имя:DES, где DES — это название алгоритма шифрования. Файл можно создать стандартной консольной программой, входящей в состав Apache, htpasswd. Описание ее использования смотрите ниже

Эту директиву нужно указывать только, если вы указали значение для директивы Request(смотрите ниже) равном group

Этот файл содержит информацию о допустимых группах пользователях для входа. Формат файла: Группа:Имя Имя : Имя. Т.е только те пользователи, которые существуют и которые входят в группы, описанные в директиве Require(смотрите ниже), смогут войти

Значения: Require (user Имя Имя : Имя | group Группа Группа : Группа | valid-user

Эта директива определяет принцип аутентификации:

* User — только пользователи, указанные следующими через пробел, и указавшие верный пароль, смогут войти
* Group — только пользователи, входящие в группы, указанные следующие через пробел, и указавшие верный пароль, смогут войти. Указание директивы AuthGroupFile обязательно
* Valid-user — любой пользователь, существующий в файле AuthUserFile, и указавший верный пароль, сможет войти

На этом директивы, необходимые для метода AuthType Basic, перечислены. Другие директивы, относящиеся к методу AuthType Digest, я перечислять не буду, т. к они имеют узконаправленное действие и в общих системах не используются
Утилита Apache htpasswd

Читайте также:  Windows 10 не включается потоковая передача мультимедиа

Эта консольная программа создает файлы, указываемые в директиве AuthUserFile. Файл хранит связки Имя:Пароль для доступа к защищенной части сайта

Обычно программа поставляется вместе с Apache и находиться в папке bin ее корневой папки

Формат вызова утилиты:

Параметры командной строки

Часть файла httpd.conf

Для создания файла паролей для первого примера

Входим в shell и пишем такие команды

На этом я закончу свое описание здесь средств защиты данных web-сервером Apache. Все пожелания или вопросы можете оставлять по нижеследующим координатам

На данное время (Июль 2006 года) я пишу Content Managing System(CMS) под PHP 4+, MySQL 3.23.xx+ и Apache 1.3+, всем желающим посмотреть или присоединиться — пишите мне сюда же

Источник

Настройка Apache для работы 1С через HTTPS (SSL)

Установка Apache

1. Идем на сайт https://www.anindya.com/ и качаем файл apache_2.4.23-x64-openssl-1.0.2h.msi (цифры на момент скачивания могут быть другими).

2. Устанавливаем Apache.

Реквизиты в полях Network Domain, Server Name и Administartor Email произвольные.

Жмем Next > Next > Next. Выбираем Typical.

3. Проверим, что сайт доступен по localhost. Откройте браузер и введите localhost в адресную строку. Должна открыться страница с текстом «It Works!«

Настройка Apache по SSL

4. Отлично. Apache установлен, теперь давайте настроем его работу по SSL.

Находим в папке c:\Program Files\Apache Software Foundation\Apache2.4\conf файл httpd.conf

Дописываем строку Listen 443
Это стандартный порт HTTPS. Заставляем Apache слушать и этот порт тоже. Если нам не нужен стандартный 80-ый порт и мы не планируем его использовать, то строку Listen 80 можно закомментировать добавив символ # (решетки) в начале строки. Так же имейте ввиду, что при изменении файлов в папке Program Files потребуется открытие файла в режиме администратора.

Раскомментируем в файле httpd.conf строчку
#LoadModule ssl_module modules/mod_ssl.so
Убрав символ #. Т.е. строка должна стать такой:
LoadModule ssl_module modules/mod_ssl.so

4. В конце файла httpd.conf изменяем

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLSessionCache none

Записываем файл httpd.conf

5. Из каталога bin установленной папки с Apache cкопируем файлы ssleay32.dll и libeay32.dll в C:\Windows\System32. Так же скопируем файл openssl.cnf из папки c:\Program Files\Apache Software Foundation\Apache2.4\conf\ в папку c:\Program Files\Apache Software Foundation\Apache2.4\bin\.

6. Запустим редактор реестра regedit (Пуск > Выполнить ввести текст regedit и нажать Enter) откроется окно реестра в нем найдем ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Apache2.4
В этой ветке найдем переменную ImagePath и два раза кликнем на ней.

Добавим ключ запуска -D ssl

7. Добавим SSL-сертификаты для домена. Тут есть варианты.

7.1. Если у Вас уже есть SSL-сертификаты для домена, то создайте папку ssl в папке C:\Program Files\Apache Software Foundation\Apache2.4\conf и переместите их туда (файлы *.key и *.cert). Идем на шаг 8.

7.2. Если у Вас нет SSL-сертификатов, то вы можете их сгенерировать самостоятельно.

Идем по шагам в командной строке и заполняем необходимые поля. То, что вы введете не принципиально. Самое главное на этом этапе надо запомнить пароль (когда спросит pass phrase)

8. Снова открываем файл httpd.conf из папки C:\Program Files\Apache Software Foundation\Apache2.4\conf и добавляем секцию VirtualHost в самый конец файла httpd.conf:

SSLEngine On
SSLCertificateFile conf/ssl/ssl.cert
SSLCertificateKeyFile conf/ssl/ssl.key

Вместо адреса demo.soft.ru замените на свой сайт или IP-адрес, а можно вообще поставить звездочку (*) и будет *:443 (это означает, что сработает для всех запросов). Ну и если у вас есть свои ключи, и вы их не генерировали сами, то переименуйте ssl.cert и ssl.key

9. Перезапустим Apache. Открываем Monitor в правом нижнем углу, щелкнем по иконке и нажимаем restart. Если все хорошо, то Apache запустится без ошибок и появится зеленый значок.

10. Пробуем открыть сайт через HTTPS. В нашем случае можно и так https://localhost и вот так https://demo.soft.ru:

Обратите внимание на то, что сертификат самоподписанный и службы типа антивируса Касперского понимают, что дело не очень. Это нормально, так как ваш сертификат не был изготовлен корневыми центрами сертификации. Но если вы захотите использовать https внутри организации, то почему бы и нет?

11. Теперь попробуем запустить 1С. В браузере открывается:

Теперь попробуем открыть базу через тонкий клиент и если мы использовали самодписанный сертификат то тут нас ждет разочарование:

12. Дело в том, что сервер 1С содержит собственный контроль достоверности HTTPS-соединений и корневых центров.
Необходимо открыть папку сервера 1С:Предприятия c:\Program Files\1cv8\8.3.15.1747\bin\ и в ней найти файл cacert.pem
Он отвечает как раз за эти центры сертификации.

Открываем командную строку и в ней выполняем команду:

После выполнения команды на экране Вы увидите Fingerprint. Скопируйте его. Это будет строка вида:

Откройте файл cacert.pem в папка 1С, перейдите в конец файла и с этой строки начинайте добавление своего сертификата в файл cacert.pem. После строки контрольной суммы сертификата, нужно добавить в файл cacert.pem содержимое файла, в который Вы экспортировали сертификат.

После этого запуск тонкого клиента будет работать без ошибок.

Если же и после этого есть ошибки, то можно вообще заставить клиент 1С не проверять сертификат. Для этого необходимо отредактировать информационную базу:

Источник

Виды аутентификации

6.2.8.1. Общая информация

Аутентификация ‑ проверка принадлежности предъявленного идентификатора (имени) конкретному пользователю системы, проверка подлинности. Система «1С:Предприятие» поддерживает несколько различных вариантов аутентификации, которые будут рассмотрены в следующих разделах.

6.2.8.2. Аутентификация средствами системы «1С:Предприятие»

Пользователь может быть аутентифицирован системой «1С:Предприятие» с помощью ввода его имени и пароля (в диалоге аутентификации, в виде параметров командной строки или строки соединения с информационной базой для внешнего соединения или automation-сервера). В этом случае проверка наличия пользователя и корректности ввода его пароля выполняет система «1С:Предприятие».

6.2.8.3. Аутентификация операционной системы

Пользователь может быть аутентифицирован неявно средствами операционной системы. Для этого пользователю должен быть поставлен в соответствие некоторый пользователь операционной системы. При старте системы, «1С:Предприятие» запрашивает у операционной системы пользователя, который аутентифицирован в системе в данный момент. Для этого в ОС Windows используется интерфейс SSPI, а в ОС Linux ‑ GSS-API. Затем выполняется проверка, что данному пользователю операционной системы сопоставлен пользователь «1С:Предприятия». Если поиск заканчивается успешно ‑ считается, что пользователь системы «1С:Предприятие» аутентифицирован успешно, и диалог аутентификации не отображается.

Читайте также:  0xc0000001 ошибка виндовс 10 как исправить

ПРИМЕЧАНИЕ 1. Клиентское приложение для ОС Linux или macOS не поддерживает аутентификацию средствами операционной системы.

ПРИМЕЧАНИЕ 2. Не поддерживается аутентификация пользователя средствами операционной системы в том случае, если клиентское приложение подключается к информационной базе через веб-сервер Apache, работающий под управлением ОС Windows.

ПРИМЕЧАНИЕ 3. При работе под управлением ОС Windows, для обеспечения стабильной работы аутентификации ОС при подключении тонким клиентом через веб-сервер или с помощью веб-клиента, необходимо внести адрес используемой информационной базы в список надежных сайтов свойств веб-браузера (Панель управления ‑ Сеть и интернет ‑ Свойства браузера ‑ Безопасность).

Пользователь операционной системы указывается в формате: \\имя_домена\имя_пользователя. При этом имя пользователя не должно содержать символы алфавитов, отличных от латинского алфавита. Формат имени домена и имени пользователя может зависеть от настроек контроллера домена и учетных записей в нем. Определить правильное написание пользователя операционной системы можно по его представлению в событии CONN технологического журнала в свойстве Txt, которое начинается с текста Srvr: DstUserName2:. Например, событие 30:30.551013-0,CONN,2,process=rmngr,OSThread=24204,t:clientID=3,Txt=Srvr: DstUserName2: d1.d2\user1(d1.d2\user1) значит, что в качестве имени пользователя операционной системы в описании пользователя информационной базы должно быть указано \\d1.d2\user1.

Если необходимо принудительно выполнить аутентификацию средствами системы «1С:Предприятие», то в командной строке запуска клиентского приложения следует указать параметр командной строки /WA-. Соответственно, параметр командной строки /WA+ предназначен для принудительного применения аутентификации средствами операционной системы (действует по умолчанию).

● Технологический журнал (см. здесь).

6.2.8.4. Аутентификация с помощью OpenID

OpenID (http://openid.net/) ‑ это протокол, который позволяет пользователю использовать единую учетную запись для аутентификации на множестве не связанных друг с другом ресурсов, систем и т. д. Система «1С:Предприятие» использует протокол, созданный на основе протокола OpenID версии 2.0 по модели Direct Identity.

ПРИМЕЧАНИЕ. Данный способ аутентификации не применим при обращении к веб-сервисам, опубликованным из «1С:Предприятия».

Общая схема работы выглядит следующим образом:

● Пользователь пытается выполнить вход в систему.

● Система определяет, что в информационной базе работает OpenID-аутентификация (по файлу публикации default.vrd).

● Провайдеру OpenID отправляется запрос на выполнение аутентификации. Очевидно, что OpenID-провайдер должен быть доступен для обращения с того адреса, на котором опубликована информационная база.

● Если необходимо выполнить интерактивное действие (выполняется первая аутентификация для данного идентификатора или истекло время жизни аутентификационных данных данного идентификатора), то провайдер сообщает системе о необходимости запросить имя и пароль пользователя. Система выполняет интерактивное действие и возвращает провайдеру OpenID запрошенные данные.

Аутентификационные данные пользователя хранятся в файлах cookie, которые размещаются в хранилище, индивидуальном для каждого веб-браузера. Тонкий клиент использует собственное хранилище.

● Если провайдер аутентифицирует пользователя, то системе возвращается признак того, что пользователь аутентифицирован.

OpenID-аутентификация работает только в тех случаях, когда доступ к информационной базе осуществляется по протоколу HTTP и HTTPS. Это означает, что использовать OpenID-аутентификацию могут только веб-клиент, мобильный клиент, а также тонкий клиент, подключенный к информационной базе через веб-сервер. При OpenID-аутентификации возможны кросс-доменные запросы при работе с помощью тонкого клиента, а также с помощью веб-браузеров Mozilla Firefox, Google Chrome, Safari и Microsoft Internet Explorer версий 8 и 9. В веб-браузере Microsoft Internet Explorer версий 6.0 и 7, после ввода имени пользователя и пароля, открывается окно сообщения с запросом подтверждения на выполнение операции. Если пользователь подтверждает выполнение операции ‑ процесс аутентификации продолжается. В противном случае вновь предлагается ввести имя пользователя и пароль.

В качестве OpenID-провайдера может выступать как информационная база «1С:Предприятия», опубликованная на веб-сервере специальным образом, а также произвольная информационная система, которая реализует работу по протоколу OpenID Authentication 2.0 и расширение этого протокола, реализованное в платформе «1С:Предприятие». Адрес используемого OpenID-провайдера следует указать в файле default.vrd (элемент ) при публикации информационной базы, выступающей клиентом OpenID-провайдера.

Важно понимать, что «ключевым» полем, по которому обеспечивается сопоставление пользователя информационной базы «1С:Предприятия» и базы пользователей OpenID-провайдера, выступает значение, указанное в свойстве Имя пользователя информационной базы. Другими словами пользователь сможет войти в информационную базу в том случае, если в информационной базе, в свойстве Имя будет указан идентификатор, возвращаемый OpenID-провайдером. Описание возвращаемого идентификатора необходимо получать в документации к используемому OpenID-провайдеру.

Пароль пользователя указывается в рамках OpenID-провайдера. Если в роли OpenID-провайдера выступает информационная база «1С:Предприятие», то пароль задается в информационной базе, выступающей в роли OpenID-провайдера. Пароль, заданный в информационной базе, которая является клиентом OpenID-провайдера, игнорируется при выполнении аутентификации с помощью OpenID. Если используется сторонний OpenID-провайдер, то пароль задается с помощью средств и инструментов этого провайдера. После того, как в хранилище пользователей OpenID-провайдера сменили пароль пользователя, система «1С:Предприятие» будет следовать следующим установкам:

● в текущих сеансах этот пользователь будет считаться аутентифицированным до завершения сеансов;

● при создании нового сеанса будет выполнен запрос пароля даже в том случае, если аутентификационные данные пользователя еще не устарели.

Если необходимо принудительно выполнить аутентификацию с помощью OpenID, то в командной строке запуска клиентского приложения следует указать параметр командной строки /OIDA+ (действует по умолчанию). Соответственно, параметр командной строки /OIDA‑ предназначен для принудительного отключения аутентификации с помощью OpenID.

Подробнее о настройке веб-сервера для работы с OpenID-аутентификацией см. здесь.

● Дополнительные требования к OpenID-провайдеру (см. здесь).

6.2.8.5. Аутентификация с помощью OpenID Connect

OpenID Connect (http://openid.net/connect/) ‑ это протокол, который является расширением протокола авторизации OAuth 2.0. OpenID Connect позволяет системе «1С:Предприятие» проверить личность пользователя на основе аутентификации, выполненной сторонним провайдером. Данный протокол применим только для работы веб-клиента. Система «1С:Предприятие» не может выступать в роли провайдера OpenID Connect. Для работы используются только внешние провайдеры.

Для сопоставления пользователя «1С:Предприятия» и пользователя провайдера аутентификации используется электронная почта пользователя. Для системы «1С:Предприятие» она предоставляется провайдером OpenID Connect. Электронная почта пользователя должна быть указана в свойстве Имя пользователя информационной базы.

Описание схемы работы с использованием провайдера OpenID Connect см. здесь.

Источник

Поделиться с друзьями
admin
Советы экспертов и специалистов