Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Реализовано в версии 8.3.15.1489.
Мы реализовали механизм, с помощью которого вы можете выполнять двухфакторную аутентификацию пользователей информационной базы. Он позволяет запрашивать у пользователя аутентификационные данные двух разных типов. Это обеспечивает более эффективную защиту от несанкционированного проникновения в информационную базу.
Применительно к системе 1С:Предприятие аутентификация – это процедура проверки логина и пароля, которые ввёл пользователь, на корректность. Эту операцию платформа может выполнять самостоятельно, либо может воспользоваться результатами аутентификации, которую выполнил другой ресурс, которому она доверяет (операционная система или аутентификация OpenID). В любом случае либо там, либо там пользователь выбирает некоторый логин и вводит пароль. Если логин и пароль корректные, платформа считает, что пользователь идентифицирован и предоставляет ему доступ к данным.
Эта привычная парадигма (логин / пароль) проста и удобна, но обладает одним концептуальным недостатком. Пароль надо помнить, для этого он должен быть коротким и простым. Но такие пароли легко взломать. Чтобы пароль было трудно взломать, он должен быть длинным и сложным. Но такие пароли запомнить непросто. По этой причине в реальности всё сводится к тому, что люди используют простые пароли, причём в разных местах одни и те же.
Двухфакторная аутентификация - это способ, позволяющий, с одной стороны, значительно усложнить злоумышленникам доступ к чужим данным, а с другой стороны - это решение, которое позволяет в какой-то степени нивелировать недостатки классической парольной защиты.
Двухфакторная аутентификация требует, чтобы пользователь имел два из трех возможных типов аутентификационных данных:
Смысл двухфакторной аутентификации заключается в том, что для того, чтобы куда-то попасть, пользователь должен дважды подтвердить тот факт, что он – это он, причём, разными способами. Например, ввести логин / пароль (первый фактор), а затем ввести код, присланный на его мобильный телефон (второй фактор).
Проверку первого фактора аутентификации выполняет платформа 1С:Предприятия, а для работы со вторым фактором аутентификации используется некоторый сторонний сервис, который мы будем называть провайдером.
Провайдер - это веб-сервис, обладающий некоторым интерфейсом, состоящим из HTTP-запросов. Это может быть, например, база 1С:Предприятия, в которой вы реализовали набор HTTP-сервисов, позволяющих пересылать сообщения или выполнять аутентификацию. Это может быть сторонний сервис, пересылающий сообщения по СМС или электронной почте, это может быть сервис, генерирующий коды второго фактора аутентификации или сервис, взаимодействующий с пользователем через собственное мобильное приложение, и так далее. Важно лишь, что к провайдеру можно обращаться посредством HTTP-запросов.
Чтобы дальнейший рассказ был более понятным, рассмотрим сразу два сценария аутентификации, которые позволяет реализовывать новый механизм.
Итак, стандартная аутентификация 1С:Предприятия (первый фактор) выглядит следующим образом:
Если второй фактор использовать не нужно, то считается, что пользователь полностью идентифицирован и может начинать работу. Это привычный сценарий аутентификации, который существует в платформе сейчас.
А вот если для этого пользователя нужно использовать второй фактор, то дальше возможны два новых сценария использования второго фактора аутентификации.
Этот сценарий можно использовать для «простых» провайдеров второго фактора, которые могут только передать фиксированное сообщение пользователю (например, с помощью СМС сообщения на номер телефона). В этом сценарии платформа (сервер) сама генерирует код второго фактора и полностью формирует сообщение, которое провайдер должен передать пользователю. Провайдер только передает сообщение пользователю, а платформа ожидает, когда пользователь введёт код второго фактора в окно дополнительной аутентификации.
Этот сценарий можно использовать для «умных» провайдеров второго фактора. Для таких провайдеров, которые, например, сами генерируют секретный код, сообщение, сами умеют информировать пользователя и проверять его данные. Предполагается, что такой провайдер заранее имеет информацию о пользователе, которая ему необходима (например, от разработчика или администратора прикладного решения). Провайдер самостоятельно выполняет аутентификацию второго фактора, а платформа ожидает сигнала от пользователя, чтобы запросить у провайдера результат этой аутентификации.
То, у какого провайдера и каким образом выполнять аутентификацию второго фактора, определяется для каждого пользователя отдельно.
Чтобы описать HTTP-запросы, которые следует отправить провайдеру, мы реализовали во встроенном языке новый тип – ШаблонНастройкиВторогоФактораАутентификации. Объекты этого типа - это именованные объекты, которые вы можете сохранять в базе данных. Каждый такой шаблон позволяет сохранить сразу два HTTP-запроса: один для запроса аутентификации, другой – для получения её результата. Оба этих запроса описываются с помощью привычных объектов HTTPЗапрос, но имеют две интересные особенности:
В результате, например, шаблон для простого провайдера, отправляющего СМС, вы можете сформировать, задав только один запрос – запрос для аутентификации. В этом запросе будут использованы два параметра – host (адрес провайдера) и secret (код второго фактора, который сформирует платформа):
Шаблон «умного» провайдера будет содержать уже два запроса (просьба выполнить аутентификацию и запрос результатов аутентификации):
После того, как вы сохранили один или несколько шаблонов для провайдеров, вы можете каждому пользователю назначить определенный шаблон и набор значений для параметров, которые должны подставляться в этот шаблон.
Например, для пользователя, который будет использовать «простого» провайдера вы можете записать единственный параметр – адрес, на который будет отправляться HTTP-запрос (host):
А для пользователя, который будет использовать «умного» провайдера, параметров понадобится больше:
Обратите внимание, что каждому пользователю можно задать не один «набор» настроек, а несколько (массив). Свойство ОбработкаНастроекВторогоФактораАутентификации позволяет применять их по очереди в том случае, если исполнение текущего HTTP-запроса закончилось ошибкой. Например, провайдер не работает, тогда можно попробовать другого провайдера, который умеет выполнять аналогичные действия (другой набор настроек).
Для всех новых сценариев аутентификации мы добавили в журнал регистрации новые события и новые поля некоторым старым событиям. Поэтому вы сможете контролировать не только сами процессы аутентификации, но и связанные с ними действия: изменение шаблонов второго фактора аутентификации, а также изменение настроек пользователей, связанных с двухфакторной аутентификацией.