Комментарии 24
Как видно из схемы, используется 2 логина/пароля (на вход в систему, на вход в программу) и одноразовый пароль сессии.
Немного не ясен смысл выбора имени пользователя и пароля для входа в 1С. Если пользователь прошел аутентификацию и мы уверены, что это — именно он, то почему бы сразу не использовать эту информацию и запускать в 1С сразу под его учеткой («аутентификация операционной системы» в терминах 1С)? К чему давать возможность выбора в списке другого пользователя и заниматься его брутфорсом?
А так решение весьма интересное. Возможно что-то такое через годик буду лепить.Спасибо за подсказку.
Немного не ясен смысл выбора имени пользователя и пароля для входа в 1С. Если пользователь прошел аутентификацию и мы уверены, что это — именно он, то почему бы сразу не использовать эту информацию и запускать в 1С сразу под его учеткой («аутентификация операционной системы» в терминах 1С)? К чему давать возможность выбора в списке другого пользователя и заниматься его брутфорсом?
А так решение весьма интересное. Возможно что-то такое через годик буду лепить.Спасибо за подсказку.
Реализация прозрачной аутентификации, как вы предлагаете, потребует изменений каждой публикуемой базы. Это повлечет за собой дополнительные затраты на поддержку такого решения для тысяч баз в нашем облаке.
Кроме того довольно часто один и тот же пользователь работает в нескольких разных базах одновременно, что создаст дополнительные трудности при организации прозрачного доступа.
В общем, большого преимущества в реализации такого решения я что-то не увидел, одни неудобства. В описанном же варианте у меня есть возможность предоставлять доступ к любым базам 1С штатными средствами без каких-либо доработок и изменений.
Кроме того довольно часто один и тот же пользователь работает в нескольких разных базах одновременно, что создаст дополнительные трудности при организации прозрачного доступа.
В общем, большого преимущества в реализации такого решения я что-то не увидел, одни неудобства. В описанном же варианте у меня есть возможность предоставлять доступ к любым базам 1С штатными средствами без каких-либо доработок и изменений.
Я правильно понял, что бы открыть базу надо ввести пароль три раза:
1. При входе на сайт
2. После успешной авторизации одноразовый.
3. Пароль 1С?
1. При входе на сайт
2. После успешной авторизации одноразовый.
3. Пароль 1С?
На данный момент да. Но возможно, мы сделаем прозрачную аутентификацию после ввода одноразового пароля.
Хотим уточнить, что нами был рассмотрен случай с дополнительной аутентификацией пользователя средствами 1С как наиболее общий и учитывающий специфику работы наших клиентов. Большинству из них требуется работа под несколькими учетными записями в рамках одной терминальной сессии. Прозрачная аутентификация для нашей конкретной задачи не нужна.
Разумеется, мы используем аутентификацию средствами ОС при заведении пользователей в базах 1С, если у клиента возникает соответствующее пожелание.
В таком случае аутентификация сводится к вводу паролей на следующих этапах:
1. При входе на сайт (доменная учетная запись).
2. Одноразовый код, полученный по СМС, после успешного прохождения п.1.
Разумеется, мы используем аутентификацию средствами ОС при заведении пользователей в базах 1С, если у клиента возникает соответствующее пожелание.
В таком случае аутентификация сводится к вводу паролей на следующих этапах:
1. При входе на сайт (доменная учетная запись).
2. Одноразовый код, полученный по СМС, после успешного прохождения п.1.
Реализация прозрачной аутентификации, как вы предлагаете, потребует изменений каждой публикуемой базы. Это повлечет за собой дополнительные затраты на поддержку такого решения для тысяч баз в нашем облаке.
Кроме того довольно часто один и тот же пользователь работает в нескольких разных базах одновременно, что создаст дополнительные трудности при организации прозрачного доступа.
1) На ваших скриншотах не увидел выбора списка баз после авторизации на портале через СМС. Или, в случае доступа всего к одной базе, вы делаете сразу переход в нее?
2) В случае прозрачной аутентификации (когда логин/пароль с портала совпадает с логином/паролем в базе) нет нужды в изменении баз. При переадресации на внутреннюю ссылку используйте GET-параметры ?N=login&P=password
А почему SMS, а не TOTP? Смартфоны сейчас у всех.
TOTP есть и на аппаратных ключах, а вариантов для смартфонов еще больше: Google Authentificator (TOTP/HOTP), MOTP (MD5+Pin) etc.
У бухгалтеров, как выяснилось, далеко не у всех есть смартфоны.
Java-то сейчас на всех телефонах есть? Для Java есть TOTP-генераторы.
И если уж у них совсем телефоны типа Siemens A52, то ради безопасности можно выдать самые дешёвые телефоны с java.
И если уж у них совсем телефоны типа Siemens A52, то ради безопасности можно выдать самые дешёвые телефоны с java.
SMS — это вообще не безопасность по большому счёту, т.к. по сговору с человеком в салоне оператора можно получить дубликат симки, что успешно проделывается с пабликами ВК (делают дубликат симки и уводят сообщества).
Тем не менее банки не брезгуют подтверждением денежных переводов по коду, отправленному через SMS.
.Тут несколько причин:
1) Клиенты банков — простые люди, понятия не имеющие об аутентификаторах, SMS проще.
2) Некоторые банки (Альфа) проверяют уникальный идентификатор сим-карты, куда отправляют смс, даже после легальной замены нужно ехать в офис с документами.
3) В договорах с банками прямо оговаривается, что подтверждение по SMS однозначно аутентифицирует клиента, и на увод денег таким способом банкам, по большому счёту, по барабану.
Вам на сохранность своих данных не по барабану. Как и банкам, кстати, у них пользователи (не клиенты), где я видел, аутентифицируются именно по физическим TOTP-токенам.
1) Клиенты банков — простые люди, понятия не имеющие об аутентификаторах, SMS проще.
2) Некоторые банки (Альфа) проверяют уникальный идентификатор сим-карты, куда отправляют смс, даже после легальной замены нужно ехать в офис с документами.
3) В договорах с банками прямо оговаривается, что подтверждение по SMS однозначно аутентифицирует клиента, и на увод денег таким способом банкам, по большому счёту, по барабану.
Вам на сохранность своих данных не по барабану. Как и банкам, кстати, у них пользователи (не клиенты), где я видел, аутентифицируются именно по физическим TOTP-токенам.
мы протестировали вариант использования токенов… Токены — не самое удобно решение, так как приходится покупать отдельный токен для каждого пользователя и ставить на компьютеры пользователей дополнительное ПО.
с токенами по RFC 6238 никакого ПО на клиенте не нужно вообще, токены полностью изолированы от компьютера пользователя
и вариант получения пароля по электронной почте.
И правильно что отказались, ибо это была бы не двухфакторная авторизация на самом деле, ведь почта-то защищено только паролем
Еще комментарий по поводу Swivel, немного не понял зачем он нужен. Если Swivel на лету проверяет и палоь в AD и второй фактор, то понятно, но у вас пользователь авторизуется в 1С повторно… если Swivel был нужен только как RADIUS сервер для отправки СМС и проверки одноразового пароля, то с эти прекрасно мог бы справиться любой радиус, в том числе и бесплатный freeRadius
Согласен. То, как у нас получилось реализовать задачу в конечном итоге, можно было бы сделать и используя бесплатное ПО (например freeradius + Linotp).
Изначально мы не планировали использовать RADIUS и UAG, хотели аутентифицировать сразу на IIS. А для IIS у Swivel есть плагины (вообще у них очень много разных интеграций с другим ПО).
Однако из-за того, как реализовна публикация 1С на IIS, эта схема оказалась не работающей (конфликт плагина 1С и Swivel).
Спасибо за идею, посмотрим, на сколько бесплатное ПО нам подходит.
Изначально мы не планировали использовать RADIUS и UAG, хотели аутентифицировать сразу на IIS. А для IIS у Swivel есть плагины (вообще у них очень много разных интеграций с другим ПО).
Однако из-за того, как реализовна публикация 1С на IIS, эта схема оказалась не работающей (конфликт плагина 1С и Swivel).
Спасибо за идею, посмотрим, на сколько бесплатное ПО нам подходит.
А что именно в IIS отвечает за авторизацию? У меня была похожая задача с Citrix Web Interface, тоже на IIS, и получилось добиться того же путем пары строчек в коде (C#) и без радиуса.
В общем случае при публикации 1С через WEB IIS не проводит аутентификацию. Все запросы к web обрабатываются DLL-кой от 1С и сразу передаются в приложение. Приложение уже спрашивает данные аутентификации и предоставляет доступ в систему.
Возможно, что внутри 1С можно изменить окно входа, написать обработку, которая позволит обработать одноразовый пароль, но мне трудно сказать, сколько потребуется времени на такую разаботку. Готовых таких решений я не видел.
Было бы здорово иметь встроенную в 1С поддержку двухфакторной аутентификации, тогда вообще не нужно будет городить подобную схему.
Возможно, что внутри 1С можно изменить окно входа, написать обработку, которая позволит обработать одноразовый пароль, но мне трудно сказать, сколько потребуется времени на такую разаботку. Готовых таких решений я не видел.
Было бы здорово иметь встроенную в 1С поддержку двухфакторной аутентификации, тогда вообще не нужно будет городить подобную схему.
А в типовых это реализовано в БСП, самое главно?
я сделал авторизацию через Flash-Call от Plusofon, т.к. СМС очень дорогие.
В типовых не поддерживается заложенный в платформу механизм двухфакторной авторизации.
И да - видимо 1С в сговоре с опсосами, поэтому длину кода авторизации они заложили 5, и поменять ее на 4 нельзя.
Пришлось проверку делать при входе в 1С, средствами приложения, а не платформы.
А не получится так, что первые две авторизации пользователь пройдет под ограниченным оператором склада, а третью - введет данные коммерческого директора?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение двухфакторной аутентификации при подключении к 1С