Всё об аутентификации в 1С

Меня зовут Дмитрий Абрамов, я руководитель направления разработки 1С компании Bellerage.

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

Что такое аутентификация и какие способы есть в 1С

Аутентификация – это процесс проверки подлинности пользователя. Цель аутентификации – удостовериться, что пользователь именно тот, за кого себя выдает.

Важно отличать аутентификацию от авторизации:

• Аутентификация – это подтверждение личности. Она отвечает на вопрос «Кто вы?»,

• Авторизация – это проверка прав доступа. Она отвечает на вопрос: «Что вы здесь можете делать?».

Аутентификация вас идентифицирует и пускает в систему, а авторизация определяет ваши права в системе. Но мы сейчас сосредоточимся только на аутентификации – про RLS, роли и права доступа говорить не будем. Да и вообще привычного кода на 1С будет не так много, но все-таки будет.

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

1. Логин и пароль.

2. Аутентификация ОС

3. OpenID 2.0

4. OpenID Connect

5. JWT (8.3.21)

6. QR (8.3.26)

7. Код по почте (8.3.27)

Обратите внимание, что для относительно новых способов в этом списке стоит пометка, начиная с какой версии этот способ доступен.

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

Стандартная аутентификация. Она же логин и пароль, она же basic

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

В рамках этого механизма мы можем:

• Управлять видимостью списка пользователей.

• Устанавливать политику паролей.

• Задавать параметры блокировки пользователей при вводе.

• Проверять раскрытие пароля пользователя (8.3.26).

• Выбрать алгоритм хэширования пароля.

• Настроить способы восстановления пароля.

• Сохранять аутентификацию (8.3.26).

Давайте чуть подробнее разберем каждую из этих возможностей.
 

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

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

Как еще можно настроить эту видимость? Если вы используете конфигурацию на основе БСП, можно настроить поведение этой опции для всех пользователей по умолчанию. В меню «НСИ и администрирование» – «Настройки пользователей и прав» есть пункт «Настройка входа». Там можно установить один из четырех вариантов:

• «Включена для новых пользователей»;

• «Выключена для новых пользователей»;

• «Скрыта и включена для всех пользователей»;

• «Скрыта и выключена для всех пользователей».

При выборе двух последних вариантов эта опция просто скрывается из карточки пользователя в БСП – ее даже не будет видно.

Но следует учитывать, что эта настройка применима только в случае, если вы создаете пользователя средствами БСП, а не через конфигуратор.

Есть общая рекомендация – эту опцию выключать. Потому что для злоумышленника знание о том, что в организации есть бухгалтер Галина Степановна – уже довольно ценная информация. Он может поискать Галину Степановну в рабочих чатах, позвонить ей от лица генерального директора и спросить: «Галина Степановна, не хотите мне сказать ваш пароль?»

А для пользователей с административными правами – это уже даже не рекомендация, это скорее правило. Не показывайте логины, которые у вас есть в системе. Лучше просто выключите.
 

Вторая возможность стандартного способа аутентификации – это установка политики паролей пользователей.

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

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

При включении опции «Проверка сложностей паролей пользователей» платформа начинает проверять следующие факторы:

• Минимальная длина должна быть больше или равна значению в настройке «Минимальная длина паролей пользователей» – при этом длину меньше 7 установить не получится.

• Пароль должен включать символы трех из перечисленных групп: заглавные буквы, строчные буквы, цифры, специальные символы.

• Пароль не должен совпадать с именем пользователя

• Пароль не должен являться последовательностью символов – вы не сможете просто перебрать алфавит и написать что-то вроде «АБВГДЕЁЖЗ».

Однако если вы не включили проверку сложности пароля, поздравляю – пользователи смогут устанавливать пароли «12345» или «qwerty».

Еще из интересного – без включения проверки сложности пароли «Parol» и «PAROL» для 1С идентичны. Неожиданно, да? Вроде регистр разный, а 1С будет думать, что это одно и то же.

Из этого вытекает забавный факт – если сначала проверка сложности пароля не использовалась и пользователь вводил свой пароль как угодно, но не так, как он задумал его изначально, то после включения этой опции он почему-то вдруг со своим паролем уже зайти не сможет.

Также малоизвестный факт – что политику паролей пользователей можно устанавливать не только на всю систему целиком, но и индивидуально для конкретных пользователей. Это можно сделать через встроенный язык – создав политику с нужными настройками через менеджер ПолитикиПаролейПользователей, и назначив имя этой политики свойству ИмяПолитикиПаролей у пользователя. Никакой визуальной настройки для этого нет.
 

Третья возможность стандартного способа аутентификации – это защита от перебора паролей.

Начиная с версии 8.3.16 в платформу встроили защиту от перебора паролей. Эта настройка выполняется либо в конфигураторе в «параметрах информационной базы», либо через стандартную обработку «Блокировка аутентификации».

Работает это следующим образом: если пользователь несколько раз неудачно попытается зайти в систему (по умолчанию установлено ограничение в 3 или 5 попыток), то именно для этого имени пользователя будет установлена блокировка входа.

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

Условно, если у заблокированного пользователя имя «Администратор», а код дополнения – «_!Infostart», он сможет зайти в систему только под таким странным именем – «Администратор_!Infostart».

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

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

Список заблокированных пользователей можно посмотреть через стандартную обработку в режиме предприятия – там же можно настроить параметры блокировки и при необходимости снять блокировку с пользователя.

У механизма блокировки аутентификации есть несколько особенностей, которые нужно отметить:

• Во-первых, он работает только в клиент-серверном варианте – в файловом варианте это не работает.

• Перезапуск кластера серверов сбрасывает все счетчики.

• Если заблокирован единственный администратор, сбросить блокировку можно только перезапуском кластера серверов – поэтому имейте хотя бы два администратора.

• Кодов дополнения может быть несколько – они могут быть перечислены через точку с запятой.
   

Помимо политик паролей, в платформе 8.3.26 появилась возможность проверки пароля пользователя из списка скомпрометированных и настроить поведение в случае обнаружения пароля в этом списке.

Скомпрометированные пароли – это те, которые ранее откуда-то утекли, стали известны посторонним и, по сути, больше не безопасны. В интернете существует множество сайтов с подобными реестрами – можно проверить свой пароль там.

Проверка раскрытия паролей в платформе срабатывает в следующих случаях:

• при первоначальной установке пароля пользователю – интерактивно в конфигураторе или средствами встроенного языка;

• при изменении пароля в случае восстановления через почту;

• при изменении пароля в случае истечения срока действия.

Платформа предоставляет три варианта, чтобы задать список скомпрометированных паролей, и эти варианты можно использовать совместно:

• Есть стандартный список проверки раскрытия пароля, который предоставляет сама платформа – где-то в недрах исходников платформы лежит списочек, где перечислены скомпрометированные по мнению фирмы 1С пароли.

• Можно подгрузить свой список в виде обычного текстового документа, где просто перечислены пароли с переносом строк. Ограничение – до 100 тысяч паролей.

• Или можно использовать внешний сервис проверки раскрытия пароля – указать адрес к внешнему API, использующему протокол haveibeenpwned версии 3. Причем можно использовать как публичный сервис, так и настроить свой собственный.

И вот тут самое интересное – как проверить пароль на вхождение в какой-то список, не передавая сам пароль? На самом деле мы не передаем сервису пароль целиком, мы отдаем только часть SHA1-хеша от пароля. Сервис возвращает список хешей скомпрометированных паролей, куда входит часть этого хеша, а далее уже сама 1С проверяет, нет ли из полученного списка «нашего полного».
 

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

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

До версии 8.3.26 для хэширования использовался только алгоритм SHA-1. Сейчас он признан небезопасным – считается, что существует возможность восстановления пароля из полученного хэша. Поэтому начиная с версии 8.3.26 платформа поддерживает несколько более надежных алгоритмов:

• SHA-1

• SHA-256

• SHA-512

• PBKDF2-SHA256

Казалось бы, новые алгоритмы лучше и безопаснее, значит, нужно использовать именно их. Но есть несколько нюансов.

• Чем надежнее алгоритм, тем больше ресурсов он потребляет. Например, PBKDF2-SHA256 для процессора примерно в 2000 тяжелее, чем SHA-1 – если у вас в базе много пользователей, сервер будет целиком загружен одной только аутентификацией. Учитывайте это и используйте что-то попроще.

• Хэши паролей для новых алгоритмов хранятся вместе с «солью» – специальным ключом, добавляемым к паролю, чтобы для одинаковых паролей был разный хэш.

• Если вы перешли на платформу 8.3.26 и изменили там алгоритм хеширования паролей пользователей, а потом вернулись на 8.3.25, ваши пользователи больше не смогут зайти по паролю. Поэтому меняйте алгоритм хэширования только когда точно уверены, что уже не будете откатываться.

• Можно сделать переход более плавным – через встроенный язык указать для каждого пользователя свой алгоритм хеширования. В этом случае вы можете часть пользователей перевести на новый алгоритм хеширования, а часть – оставить на старом.
   

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

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

Там же есть возможность настроить альтернативный вариант восстановления пароля – путем перехода по навигационной ссылке, например, на веб-сайт. И уже на этом веб-сайте другими методами реализован алгоритм восстановления пароля.

Важный момент – выбрать оба способа восстановления пароля одновременно невозможно. Вы выбираете вариант восстановления либо через почту, либо через внешний сайт.

Если выбран вариант восстановления через почту, то для отправки кодов можно использовать стандартный сервис фирмы «1С» – установить флаг «Использовать стандартный сервис отправки».

Если безопасники такого не пропустят, а они обычно такого не пропускают, вы можете указать свои параметры SMTP сервера. Тогда в настройках отправки можно даже задать свой шаблон сообщения в виде HTML – кастомизировать сообщение в корпоративном стиле, используя параметры:

• ApplicationPeresentation – представление конфигурации, которая используется в текущей информационной базе.

• UserName – имя пользователя.

• UserPresentation – полное имя пользователя.

• VerificationCode – код подтверждения смены пароля.
   

И последняя возможность стандартного способа – сохранение аутентификации.

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

Настройка «Разрешить сохранение аутентификации» задается в «Дополнительных настройках аутентификации», добавляя в диалог входа флаг «Запомнить». С помощью этого флажка пользователь может запомнить вводимые параметры аутентификации и не вводить имя пользователя и пароль в течение указанного времени.

Эти же параметры могут быть заданы с помощью файла публикации информационной базы default.vrd. Причем его настройки имеют более высокий приоритет, чем настройки в информационной базе: вы можете разрешить сохранять пароль в настройках самой базы, а в файле default.vrd – запретить это делать.

Но главное – логин и пароль не сохраняются на компьютере. Сохраняется специальный токен, действие которого ограничено по времени, указанному в настройках.

И при изменении пароля пользователя сохранение аутентификации тоже сбрасывается – пароль нужно будет вводить заново.

Обратите внимание: мы пока разобрали только стандартную аутентификацию. Казалось бы, она самая простая, но на деле – самая обширная. Переходим к следующему способу.
 

Аутентификация операционной системы (ОС)

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

Этот способ особенно нравится пользователям – просто включил компьютер, и сразу можешь работать в своей 1С. Правда, если за ваш компьютер случайно сел коллега, то он тоже в вашей 1С. Надеюсь, у вас хороший кадровик, и он свой компьютер блокирует.

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

Преимущества аутентификации ОС:

• Это достаточно безопасно – там, где нет ввода логина и пароля, всегда безопаснее, чем там, где это есть.

• Это удобно для пользователей и системных администраторов.

• Это можно использовать, в том числе, для HTTP-сервисов.

Но и недостатки тоже есть:

• Во-первых, это не работает на компьютерах вне домена – если я захочу подключиться со своего домашнего компьютера, это работать не будет, придется вводить логин.

• Не поддерживается клиент macOS – а у меня как раз Mac, мне тоже неудобно.

• Не работает через веб-сервер Apache на Windows.

• В некоторых случаях требует дополнительной настройки инфраструктуры.

  • Например, если доступ идет через веб-сервер, это будет работать только если веб-сервер и сервер 1С на одной машине – если они расположены на разных серверах, потребуется дополнительная настройка делегирования Kerberos.

  • Также дополнительные настройки Kerberos потребуются при использовании сервера на Linux.
     

OpenID 2.0

Следующий способ – OpenID 2.0. Он, как мне кажется, наименее популярен из всех.

OpenID 2.0 – это протокол аутентификации, который позволяет пользователям входить в систему с использованием одной учетной записи через различные платформы.

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

Чтобы базу можно было использовать в качестве OpenID-провайдера, ее нужно опубликовать на веб-сервере с указанием специальных параметров.

Общий процесс аутентификации через OpenID 2.0 выглядит следующим образом:

1. Клиентское приложение 1С обращается к Информационной базе №1.

2. Информационная база №1 обращается к OpenID-провайдеру с тем, чтобы он аутентифицировал пользователя.

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

4. Используя признак аутентификации, сохраненный в cookie, пользователь подключается к Информационной базе №1 и начинает работу.

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

Чтобы база могла выступать в роли провайдера, в ее файле публикации default.vrd нужно указать длительность жизни сеанса в cookie.

А в других клиентских базах, чтобы они начали использовать эту базу как провайдер в файлах публикации default.vrd нужно указать путь к публикации базы провайдера, а точнее к её специальному сервису, который передает сохраненный в cookie признак аутентификации в клиентскую базу.

Вообще протокол OpenID 2.0 считается устаревшим, по нескольким причинам:

• Имена пользователей во всех информационных базах должны быть одинаковыми, а это не всегда возможно.

• Не поддерживаются современные стандарты безопасности

Поэтому на замену OpenID 2.0 пришел протокол OpenID Connect
 

JWT

Следующим логично было бы рассказать об OpenID Connect, но для его понимания стоит сначала разобраться в JWT-аутентификации.

JWT (JSON Web Token) – это открытый стандарт RFC 7519 для создания токенов доступа, основанный на формате JSON.
 

На вид такие токены выглядят как длинные «кракозябры», но на самом деле они легко раскодируются.

Токен JWT состоит из трех закодированных в Base64-URL и разделенных точкой частей:

• Заголовок (header).

• Полезная нагрузка (payload).

• Подпись (signature) – подпись можно пропустить, в таком случае токен считается неподписанным.
   

Заголовок и полезная нагрузка представляют собой объекты в формате JSON.

Заголовок содержит служебную информацию, которая помогает системе правильно прочесть и проверить данные JWT в дальнейшем. Например, там указывается используемый алгоритм подписи – эти алгоритмы бывают различными, но в целом делятся на два вида:

• симметричные (один общий секретный ключ) – обозначаются как HS…

• ассиметричные (пара открытый/закрытый ключ) – обозначаются как RS…
   

Полезная нагрузка – это обычный JSON-объект, куда записаны так называемые claims – свойства, с помощью которых конечное приложение может аутентифицировать пользователя. Эти свойства включают список зарезервированных имен полей, которые достаточно важно знать:

• iss (Issuer) – издатель токена, т.е. система/сервис, который его выпустил.

• sub (Subject) – идентификатор пользователя получателя в системе-провайдере, для кого выпущен токен.

• aud (Audience) – идентификатор системы получателя, для которой выпущен токен.

• iat (Issued At) – дата выпуска токена в виде привязки к универсальному времени.

• exp (Expiration Time) – дата истечения действия токена, до какого момента он валиден.

• nbf (not before time) – дата начала действия токена, с какого момента он валиден.

А главное – помимо этих полей издатель может вложить в токен любую другую дополнительную информацию: СНИЛС, дату рождения и прочее. Вы даже можете вложить туда какую-то свою ролевую модель – я потом расскажу, как это можно использовать.
 

В зависимости от выбранного способа подписи формируется сама подпись. С помощью подписи система-издатель гарантирует, что то, что здесь указано, этим и является.

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

Для асимметричной подписи используется криптографическая пара: публичный и приватный ключи. Этот же принцип применяется при работе с усиленными электронными подписями УНЭП и УКЭП – провайдер подписывает токен закрытым ключом и предоставляет возможность проверить этот токен открытым ключом.

Для удобной работы с JWT можно использовать ресурс jwt.io – там можно как декодировать готовый токен, так и сформировать новый в интерактивном режиме.

Разберемся, как работает аутентификация через JWT в 1С – что при этом происходит под капотом. Допустим, у нас уже есть JWT-токен – неважно, откуда он появился: он может быть сгенерирован с помощью встроенного языка 1С либо с помощью сервиса jwt.io. Чтобы можно было использовать этот токен для авторизации, мы должны:

• Включить у пользователя опцию «Аутентификация токеном доступа».

• Сконфигурировать файл публикации default.vrd.
   

На слайде – пример настройки тега accessTokenAuthentification для файла публикации default.vrd.

Обратите внимание: когда мы разбирали стандартные части тела токена, я отметил, какие зарезервированные имена полей должны быть заполнены для удачной аутентификации JWT. Наша задача – указать здесь для них соответствия:

• В поле accessTokenRecepientName указываем значение из поля aud токена

• В атрибутах поля issuer указываем остальные значения тела токена:

  • В атрибуте name указываем значение из поля iss токена.

  • В атрибуте authenticationClaim указываем поле, по которому будут сопоставляться пользователи в системе-провайдере – в нашем случае sub.

  • В атрибуте authenticationUserPropertyName указываем поле, по которому будут сопоставляться пользователи из базы 1С – в нашем случае уместно использовать name.

Особенности:

• Настройку тега accessTokenAuthentification нужно настраивать на каждый сервис и вход пользователя отдельно – если у вас пять http-сервисов, этот тег для каждого http-сервиса нужно продублировать

• Если для токена используется симметричная подпись, то в атрибут keyInformation тега issuer нужно указать ту секретную строку (желательно от 32 символов), с помощью которой 1С сможет ее проверить.
   

• Если же у вас используется асимметричная подпись, то в атрибуте keyInformation поля issuer в файле default.vrd надо указать вот такое страшное заклинание – по сути, это сертификат в формате PEM. И вот этой информации в интернете, поверьте, нет. Но если у вас для аутентификации через JWT будет использоваться внешний провайдер, настройка асимметричной подписи вам может пригодиться. При этом нужно учитывать, что если провайдер перевыпустит свой закрытый ключ, то новые токены проверку не пройдут, и надо будет отдельно настраивать публикацию под новый ключ

Но вообще, JWT токен можно использовать не только для HTTP- и веб-сервисов, но и для интерактивного входа пользователя. Для этого после настройки файла default.vrd нужно зайти в 1С, используя:

• для тонкого клиента – параметр запуска
  /AccessToken <token>

• для веб-клиента – параметр GET-запроса
  url?AccessToken=<token>

• или путем вызова http\web-сервиса с помещением в заголовок
  "Authorization: Bearer <token>"

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

Например, вы можете сгенерировать ссылку для подключения веб-клиента и прислать ее человеку на почту. Только предупредите, что ссылка действует 30 минут – потому что токен выписан на 30 минут.

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

Таким образом вы можете давать людям одноразовые ссылки на вход – это удобно и, главное, безопасно.

При передаче токена платформа сама его раскодирует и проверит следующее:

• Что подпись токена соответствует его содержимому.

• Если подпись верна, проверяется валидность времени токена по значениям полей nbf и exp – что токен уже может действовать и еще не просрочен. Например, вы можете выдать токен на месяц вперед – сейчас его использовать нельзя, а через месяц – можно.

• По параметрам публикации сверяется aud – что токен выпущен для нас.

• Из токена берется значение свойства, указанного в поле authenticationClaim параметров публикации. И по значению, указанному в authenticationUserPropertyName пытается найти в системе пользователя, на которого выписан этот токен, и убедится, что такой пользователь существует. Вы в публикации сами можете настроить, по какому полю сопоставлять – name, OSUser или email.

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

• Если аутентификация токеном доступа разрешена, пользователя пускают в систему.

Преимущества JWT:

• Гибкость – вы можете выпускать токены под каждый сервис отдельно (например, только под запуск определенного сервиса), сделать валидным определенное время. Также можно вкладывать в токен дополнительную информацию и уже на стороне 1С ее считать через встроенный язык, провести с ним дополнительные манипуляции – для этого можно использовать объект встроенного языка ТокенДоступа.

• Безопасность – можно аутентифицировать пользователя без прямой выдачи ему логина и пароля.

• Удобство администрирования – можно быстро отозвать все токены, просто поменяв секретный ключ в публикации.

Но есть один минус, который неочевиден:

• Сложно точечно отозвать конкретный JWT-токен, не перенастраивая всю систему, потому что он уже подписан и в момент подписи валиден. Но сделать это можно – например, через изменение в базе 1С значения поля, по которому сопоставляются пользователи, или реализуя собственные алгоритмы хранения использованных пользователем токенов и их блокировки уже на стороне встроенного языка 1С.

OpenID Connect

Следующий способ аутентификации – мой любимый OpenID Connect.

Это протокол является расширением протокола аутентификации OAuth 2.0, который активно использует механизм JWT.

OpenID Connect позволяет системе 1С проверить личность пользователя на основе аутентификации, выполненной сторонним провайдером. Такими сторонними провайдерами могут быть ЕСИА, ВК, Google и прочие, включая корпоративные провайдеры аутентификации типа ADFS и Keycloak.
 

На сайте ИТС есть подробная инструкция по настройке OpenID Connect в 1С – https://its.1c.ru/db/metod8dev/content/5972/hdoc/_top/openid%20connect. Поэтому я остановлюсь именно на понимании того, как этот механизм работает, а также на некоторых его особенностях.
 

OpenID Connect работает только для интерактивного входа. Для HTTP веб-сервисов он не работает – протоколом это не предусмотрено.

Вообще при работе с протоколом OpenID Connect можно применять различные схемы аутентификации, но в 1С поддерживаются только две из них – Implicit Flow и Authorization Code Flow. Implicit flow устарел, его использовать нельзя. Поэтому используем только последний – Code flow.

Как вообще работает аутентификация через Authorization Code Flow:

1. Пользователь в диалоге входа в 1С нажимает кнопку аутентификации через провайдера (например, Google, ВКонтакте и т.д.).

2. Приложение перенаправляет пользователя на страницу провайдера, передавая параметры, такие как client_id, redirect_uri, scope и response_type=code.

3. Там пользователь вводит свой логин и пароль, либо входит другими способами – это уже отдается на откуп самому провайдеру.

4. Если аутентификация выполнена успешно, провайдер перенаправляет пользователя обратно на указанный redirect_uri (в 1С).

5. При этом в параметрах перенаправления URL передается специальный код autorization code.

6. Клиентское приложение 1С считывает код авторизации из адресной строки и отправляет POST-запрос к провайдеру для обмена кода на токен, передавая код авторизации, client_id, client_secret и redirect_uri.

7. В ответ провайдер передает приложению access token, id token и refresh token. Причем этот id token – это и есть JWT-токен. Его можно настроить так, чтобы вся нужная информация о пользователе уже была прописана – name, email или телефон.

8. Приложение декодирует информацию о пользователе из id token или запрашивает информацию у провайдера, используя access token.

9. В ответ провайдер передает данные профиля пользователя.

10. И дальше уже база 1С по полученным свойствам (имя, email или телефон) находит такого пользователя в 1С и аутентифицирует его – так же, как и для JWT.

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

Все настройки OpenID Connect указываются в уже знакомом нам файле default.vrd. Примеры секции openidconnect для различных провайдеров можно также увидеть в статье на ИТС.

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

Здесь же, в секции openidconnect, вы можете отключить стандартную аутентификацию путем установки флага allowStandardAuthentication в false – чтобы вообще не было полей для ввода логина и пароля, чтобы злоумышленник не смог зайти под пользователем, зная его логин и пароль.

Но стоит учитывать, что эта настройка лишь убирает возможность интерактивного входа, в реальности вход не блокируется. Это можно проверить, запустив тонкий или веб-клиент явно с передачей параметров запуска /N и /P, в которые передается логин и пароль пользователя.

У многих может возникнуть вопрос – а как сделать, чтобы вообще не было пользователей с паролем наружу? Ответ – никак. Таковы правила безопасности – в базе 1С обязательно должен быть хотя бы один пользователь с админскими правами со стандартной аутентификацией.

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

Обратите внимание: в поле redirect_uri указывается страница перенаправления, куда провайдер перенаправляет клиента, добавив специальный код авторизации. Эта же страница должна быть указана на стороне провайдера аутентификации в качестве «Разрешенного URI перенаправления» при настройке клиента OAuth.

Очевидно, что это делается ради безопасности, чтобы не выдавать заветный код кому попало. В частности, практически во всех провайдерах есть требование, что эти приложения обязательно должны быть опубликованы по защищенному протоколу https, поэтому не советую даже начинать пробовать без неё. В нашем случае в список «Разрешенные URI перенаправления» необходимо добавить адрес:

https://<hostname_web_1c>/<1c_ib_name>/authform.html

authform.html – это специальная страничка в публикации 1С, которая как раз и обрабатывает возврат «кода».
 

После того как мы получим от провайдера id token, нужно сопоставить эту информацию с самим пользователем.

Причем можно сопоставлять не только по имени и email, но и по другим сведениям, которые отсутствуют в карточке пользователя ИБ 1С – например, по СНИЛС или нику в Telegram. Такое сопоставление можно реализовать через встроенный язык, используя свойство КлючиСопоставленияПользователя, где ключом вы указываете имя провайдера, который указан в публикации, а значение соответствует значению из токена.

Для этого в файле default.vrd в поле authenticationUserPropertyName нужно указать matchingKey, а во встроенном языке выполнить код, который сохранит в это свойство нужное нам значение поля для сопоставления.

Вообще OpenID Connect – это моя самая любимая история, она у нас в компании внедрена. Резюмирую по нему главное:

• Подходит только для интерактивной аутентификации

• Хорошо подходит для реального SSO (single sign-on) в гетерогенной инфраструктуре компании, когда используется множество различных сервисов.

• Можно использовать любые дополнительные способы аутентификации на стороне провайдера. Потому что на стороне 1С мы все-таки ограничены в возможностях аутентификации, а на стороне провайдера можно настроить все что угодно. Если безопасники требуют от 1С способ аутентификации, который она не умеет, решаем эту задачу через внешнего провайдера, а 1С перенаправляем на него. Например, на Keycloak можно сделать вообще что угодно.
   

QR-код (8.3.26)
 

Предпоследний способ – это использование QR-кода. В этом случае нам потребуется связка мобильного и десктопного приложения, опубликованных на веб-сервере.

Алгоритм входа достаточно простой:

1. Пользователь нажимает «Войти через QR».

2. На экране появляется QR-код.

3. Пользователь сканирует код.

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

5. Сканируем код внутри мобильного клиента.

6. Мобильный клиент спрашивает подтверждения входа.

7. Подтверждаем, у пользователя запускается новый сеанс в исходном приложении.

Опять же, это работает только в том случае, если база опубликована на веб-сервере
 

В этом случае в файле default.vrd должны быть дополнительно указаны настройки для скачивания и запуска мобильного клиента, а в свойствах пользователя – возможность аутентификации QR-кодом.
 

По коду из почты (8.3.27)

И последний способ, появившийся в версии 8.3.27 – это аутентификация по одноразовому коду, присланному на email.
 

Такой способ достаточно удобен для использования в корпоративном сегменте. У него есть множество очевидных плюсов.

• Снижается вероятность потери пароля – он становится особо и не нужен как таковой.

• Повышается удобство работы пользователя. Им не надо записывать пароль на бумажку и ставить везде одинаковый пароль. Ввел код один раз и все.

• И по факту отключение пользователя от почты означает и невозможность входа в саму 1С. Тем не менее я все равно рекомендую в 1С пользователей тоже отключать, если доступ им более не требуется.
   

Возможность входа по одноразовому коду через электронную почту можно в «Дополнительных настройках аутентификации».

Здесь можно указать длину и алфавит этого кода, откуда он будет отсылаться – через стандартный сервис отправки или собственный SMTP-сервер.

Для собственного SMTP-сервера можно настроить шаблон этого электронного письма, используя следующие переменные:

• ApplicationPeresentation – представление конфигурации, которая используется в текущей информационной базе.

• UserName – имя пользователя.

• UserPresentation – полное имя пользователя.

• VerificationCode – код подтверждения аутентификации.

Но самое главное – теперь доступен новый параметр запуска /EmailAuth

С его помощью можно реализовать приветственное письмо для новых сотрудников, чтобы не передавать пароль напрямую, просто дать ссылку вида:
url?EmailAuth

И как только он перейдет, ему сразу же пришлется одноразовый код на вход. И потом уже на стороне 1С можно будет обработать установку пароля (запросить новый пароль при входе).
 

Используйте двухфакторку! Она защищает от 90+% атак

На этом про способы аутентификации у меня все. Но я хотел бы еще обсудить возможности двухфакторной аутентификации.

По данным Microsoft, двухфакторная аутентификация с помощью SMS-сообщений помогает остановить примерно 99,99% автоматических атак – 96% фишинговых и 75% целенаправленных. Видимо, 0.01% остается для пользователей, которые забывают пароль, теряют телефон, а потом бегают по офису в поисках администратора.

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

Если вы будете использовать OpenID Connect, лучше настроить 2FA там, потому что платформа 1С не поддерживает второй фактор при таком способе входа.
 

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

Выводы

Есть еще несколько полезных статей ИТС, где описаны все нюансы различных способов аутентификации:

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

• Подробное описание файла default.vrd

• Проверка и формирования JWT

• Примеры настройки OpenID Connect

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

Вопросы и ответы

Стоит ли ставить двухфакторную авторизацию, если уже используется VPN, аутентификация в системе и другие уровни защиты? Не будет ли это перебором?

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

Но если часть сервисов работает «наружу», тогда это имеет смысл – вы не сможете всем внешним клиентам поставить VPN.

Вы сказали, что Open ID Connect используется только для интерактивного входа. А что вы порекомендуете для веб-сервисов, которые обмениваются данными под служебными пользователями?

Для таких сценариев лучше использовать JWT. Например, вы можете через провайдер, который используется у вас для OpenID Connect, выписать себе бессрочные офлайн-токены и интегрироваться через них между базами. В Keycloak и в других корпоративных провайдерах OpenID Connect есть такая возможность.

Более того, можно использовать JWT, чтобы «пробрасывать» пользователя: сначала получить токен интерактивно, сохранить его, а дальше выполнять обращения между базами от имени этого же пользователя.

Можно ли из 1С обратиться к внешней системе по протоколу OAuth 2.0?

Да, конечно. Работа по протоколу OAuth 2.0 условно разделяется на два этапа: получение токена и его последующее использование.

Вы можете прямо на форме 1С разместить html-страничку, которая будет отвечать за аутентификацию пользователя во внешней системе. А на стороне провайдера настроить, чтобы токен доступа при аутентификации был возвращен вам на localhost или другой удобный для вас адрес. После того как пользователь проходит аутентификацию, вы просто через встроенный язык считываете переданный по адресу редиректа URL и получаете токен, который нужно будет потом указать в заголовках запроса при работе с этой системой по протоколу OAuth 2.0.

Пример того, как это реализовано, можно подсмотреть в Библиотеке стандартных подсистем – там в «Настройках почты» есть пункт «Авторизоваться с помощью почтового сервиса», можно посмотреть как для Яндекса как раз реализован похожий сценарий.

Можно ли включить 2FA только для части пользователей, чтобы защитить только самый ответственный сегмент?

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

Более того, для разных сотрудников можно настроить разные методы двухфакторной аутентификации: SMS, email, Telegram и т.д. Система достаточно гибкая.

Можно ли использовать аутентификацию ОС для базы, опубликованной на веб-сервере Apache или IIS?

Apache на Windows не работает – даже пытаться не стоит. На Linux работает, но его нужно будет настроить.

Что удобнее – встроенная двухфакторка от 1С или Keycloak?

Я бы все-таки рекомендовал использовать OpenID Connect, и уже на его уровне делать 2FA. Потому что когда компания растет, количество информационных систем и сервисов в ней будет увеличиваться. И в какой-то момент потребность в единой точке аутентификации SSO становится неизбежной.

Поэтому я рекомендую использовать внешний провайдер – Keycloak, Okta, WSO2 или любой другой. Например, для Keycloak много готовых плагинов и богатое сообщество, что намного удобнее и надежнее, чем городить что-то свое в 1С.

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

Напрямую в OpenID Connect – вряд ли. Но с JWT это возможно: вы можете на уровне HTTP-сервиса прочитать заголовок запроса, извлечь токен и использовать его содержимое для управления правами. Правда, это придется реализовать самим программно – встроенных средств для этого нет.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD & CIO EVENT.