Аутентификация в продукте «Форсайт. Аналитическая платформа»
В продукте «Форсайт. Аналитическая платформа» доступно несколько методов аутентификации. Метод аутентификации выбирается в зависимости от требуемых мер безопасности.
Проверка учётных данных может производиться на сервере СУБД и/или в «Форсайт. Аналитическая платформа».
Настольное приложение
В настольном приложении доступны следующие базовые типы аутентификации:
Доступность базовых методов аутентификации зависит от используемой СУБД:
Тип СУБД \ Тип аутентификации
— тип аутентификации доступен;
— тип аутентификации недоступен.
Парольная аутентификация
Аутентификация производится с использованием логина и пароля. Доступна настройка парольной политики.
Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».
«Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.
Ролевая аутентификация
Ролевая аутентификация аналогична парольной, производится с использованием логина и пароля. Доступ к объектам определяется по присвоенным пользователю ролям на сервере СУБД, которые совпадают с группами в «Форсайт. Аналитическая платформа».
Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».
«Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.
СУБД возвращает список ролей пользователя. Список ролей сопоставляется со списком групп платформы. Пользователь получает права, соответствующие группам.
Доменная аутентификация
При доменной аутентификации пользователь подключается с использованием данных указанного доменного пользователя.
Для конечного пользователя доменная аутентификация не отличается от парольной, но упрощает администрирование пользователей при использовании доменных контроллеров.
Пользователь вводит доменное имя и пароль в «Форсайт. Аналитическая платформа».
«Форсайт. Аналитическая платформа» передаёт указанные учётные данные на сервер СУБД.
СУБД обращается к доменному контроллеру, доменный контроллер проверяет правильность указанных данных и делегирует «Форсайт. Аналитическая платформа» право на подключение от имени доменного пользователя с использованием временного билета.
Интегрированная доменная аутентификация
Интегрированная доменная аутентификация аналогична обычной доменной аутентификации, но для авторизации будет использован доменный пользователь, под которым был совершен вход в операционную систему.
Метод аутентификации Kerberos:
При работе с СУБД Teradata интегрированная доменная аутентификация всегда осуществляется с использованием механизма аутентификации Kerberos. Для СУБД PostrgreSQL данный механизм может быть включён опционально в дополнительных параметрах соединения с репозиторием.
Для работы по протоколу Kerberos на клиентском компьютере необходимо установить MIT Kerberos (не входит в комплект поставки «Форсайт. Аналитическая платформа»).
Пользователь вводит доменное имя и пароль при входе в операционную систему.
«Форсайт. Аналитическая платформа» передаёт указанные учётные данные на сервер СУБД.
СУБД обращается к доменному контроллеру, доменный контроллер проверяет правильность указанных данных и делегирует «Форсайт. Аналитическая платформа» право на подключение от имени доменного пользователя с использованием временного билета.
Двухфакторная аутентификация
Пользователь выполняет базовую аутентификацию в «Форсайт. Аналитическая платформа».
После запроса пользователь предоставляет «Форсайт. Аналитическая платформа» сертификат.
При совпадении сертификата «Форсайт. Аналитическая платформа» обращается к СУБД, используя предоставленные данные.
Встроенная аутентификация
При встроенной аутентификации доступ к данным СУБД происходит под встроенным администратором. Проверка прав пользователя осуществляется на уровне платформы. Учётные данные администратора хранятся в зашифрованном виде. Встроенная аутентификация настраивается через контроль доступа.
Пользователь вводит логин и пароль в «Форсайт. Аналитическая платформа».
«Форсайт. Аналитическая платформа» проверяет разрешения пользователя и обращается к СУБД, используя учётные данные встроенного администратора.
Веб-приложение
Для веб-приложения доступны все варианты аутентификации настольного приложения, при этом роль настольного приложения выполняет BI-сервер.
Дополнительно для веб-приложения доступны следующие методы аутентификации:
OAuth
Аутентификация через протоколы OAuth 1.1 и 2.0 позволяет пользователю авторизоваться под учётной записью сервиса Twitter, Google и других. Подключение к СУБД в этом случае будет производиться под сохраненными зашифрованными учётными данными администратора.
Пользователь вводит логин и пароль соответствующего сервиса.
Поставщик данных (сервис) передает BI-серверу подтверждение аутентификации пользователя.
BI-сервер обращается к СУБД, используя данные встроенного администратора.
Протокол SAML позволяет совершать обмен аутентификационными данными между поставщиком аутентификации и «Форсайт. Аналитическая платформа». Подключение к СУБД в этом случае будет производиться под сохраненными зашифрованными учётными данными администратора.
Пользователь предоставляет логин и пароль поставщику аутентификации.
Поставщик аутентификации передает «Форсайт. Аналитическая платформа» результат проверки данных пользователя.
«Форсайт. Аналитическая платформа» обращается к СУБД, используя данные встроенного администратора.
Гостевой вход
Для ознакомительной работы с веб-приложением возможна настройка гостевого входа. Пользователь сможет войти под заранее созданной гостевой учётной записью, не указывая учётных данных. При использовании гостевого входа рекомендуется ограничить права для гостевой учётной записи.
Пользователь переходит по гостевой ссылке.
BI-сервер обращается к СУБД, используя заранее введённые логин и пароль от гостевой учётной записи.
Как мы переходили на доменную авторизацию AD в 1С (двигаем SSO в компании)
Приветствую всех, если вас заинтересовала статься значит вы тем или иным образом стыкались или интересовались данным вопросом, либо просто почитать.
Данный кейс с реальной практики, проект начался в начале 2019 и все «n» баз были переведены в течении полугода на доменную авторизацию (надеюсь все понимают, что это значит), но мне больше нравится SSO.
Windows Server 2016 + AD (не рассматриваем как настраивать)
CentOS 7 + Haproxy + Comodo SSL Wildcard
Windows Server 2016 + IIS + 1C
Опишу вкратце что и как взаимодействует, вся инфраструктура доменная (кроме unix подобных), сервер с 1С-на нем поднята только 1С, сама БД на SQL-ных серверах они нам не нужны сейчас. Все публикации работают по https. конечно есть и подключение сервер база (их мы тоже не будем рассматривать так как доменная авторизация в таком режиме работает сразу и без проблем. Значит клиент с доменным устройством Windows 10 вошел в систему с доменной учеткой запускает 1С в которой прописана ссылка на базу например https://1cbase.yourdomain.com, обращается в к haproxy, тот в свою очередь согласно правилам адресует его на нужный сервер с этой базой, далее IIS принимает соединение, подхватывает доменные учетные данные и передает их в 1С. Ниже схемка:
Примерная схема работы
Вроде все понятно, конечно если об этом вы слышите в первый раз, то нужно будет почитать дополнительные материалы как настраивается каждый сервис.
Двигаемся дальше и приступаем к настройке наших сервисов
Haproxy, просто ставим с репозитория и корректируем конфиг, в моем случае сервис обслуживает не только 1С а и другие WEBы, по этому у меня настройка с 80 редиректор в 443, но для 1С в клиенте нужно писать сразу https так как клиент 1С не воспринимает редирект и прописав http вы просто никуда не попадете. Плюс который для меня важен в такой схеме что на моем маршрутизаторе открыт только 80 и 443 порты и на этом все, я не делаю для каждой БД другой порт и т.д., просто устанавливаешь в своей команде стандарт названия баз и передаешь в ТП что б они знали и могли прописать базу. хотя и это автоматизировано и у каждого сотрудника согласно должности свой список баз. Так вот ссылка всегда будет иметь нормальный для меня вид. например https://rt.yourdomain.com или https://ut.yourdomain.com или https://erp.yourdomain.com. Подняли haproxy (у меня HA-Proxy version 2.0.13) и добавляем конфиг
Можно так же использовать сертификаты Let’s Encrypt но у меня есть подписанный ЦС, а еще может быть что клиент 1С на разных ОС будет ругаться на Let’s Encrypt. Если у вас кластер 1С тогда нужно добавить еще один сервер rt_db_srv02 в backend rt_db_server
Настройка IIS, тут уже будет больше картинок.
После инстала IIS, включаем только 80й порт остальные нам не нужны так как ssl будет занимается haproxy. На картинке ниже роли, которые нужно поднять:
компоненты IIS
Я это все делаю с помощью Ansible, поэтому готовых команд PS под рукой нет. Идем дальше и не к настройке IIS, а к установке 1С:
Ставим все кроме хранилища, ковертора и проверки целосности
По стандарту заходим в консоль администрирования 1С подключаем базу и тд. В клиенте 1С на сервере на котором бы будем делать публикацию прописываем имя сервера (у нас же AD и DNS внутренний) можно без порта, но естественно если порт у вас отличный от стандартного (например, подняли еще одну службу на 1640), то его писать тоже нужно типа server1С1:1641, но если у вас кластер тогда пишем так server1С1;server1С2 (server1С1:1641;server1С2:1641) и нормальные имена нужно прописывать обязательно, так как это пойдет в конфиг IIS. Чуть не забыл, после инсталляции 1С службу, которую она создаст, необходимо запустить от имени доменного пользователя, на сервер 1С его нужно будет сделать админом, а в домене может быть обычным пользователем. главное что б мог читать пользователей с AD. Например
запуск службы от доменного пользователя
Публикуем базу как обычно, все по дефолту, с необходимыми галочками в hs/ws
И тут возвращаемся к IIS, тут уже будет публикация в 1С в сайте по умолчанию, но мы ее не трогаем пока что. это как эталон конфига. Делаем паку в C:\inetpub\wwwroot\, например rt.yourdomain.com, ну что б было все красиво и понятно тому, кто придет на этот сервер после нас или с нами. Добавляем новый веб-сайт (это, я думаю, понятно как) и заполняем:
Настройки веб-сайт
Веб сайт есть, а далее вместе с ним создается и пул приложений. который нам больше всего и нужно, так как в нем мы задаем кто будет авторизовать креды пользователей в 1С и расшифровывать karberos. Для этого нам нужен еще один доменный пользователь желательно отдельный, например iis_service (создаём помним пароль)))
Так он выглядит стандартно:
Приводим его в нужный вид, редактируя удостоверение:
Тюним, Режим управления выставляем Классический и нужно что б это удостоверение использовалось для этого делаем в редакторе конфигурации сервер (путь system.webServer/security/authentication/windowsAuthentication).
IIS настроен, переходим к нашей новой публикации rt.yourdomain.com, для начала выставляем проверку подлинности:
Копируем конфиг публикации, то есть с наше стандартной публикации берем два файла default.vrd и web.config копируем в папку C:\inetpub\wwwroot\rt.yourdomain.com, отлично. Чуть поправим конфиг, буквально удалим в одно строчке символы, что б наши ссылки были короче и красивей. В файле default.vrd удаляем как на картинке и именно так. даже если что-то было после / мы это удаляем:
делаем так
Ну и по классике что б не было кракозябликов в 1С то правим настройку страницы ошибок для нашей публикации rt.yourdomain.com:
С этим все готово. Для корректной работы, необходимо в AD прописать spn запись, это просто заходим на домен контроллер и запускаем команды, в которых пишем нашу публикацию и нашего пользователя, который расшифровывает kerberos:
В 1С пользователю вставляем авторизацию как на картинке:
Со списка доменов нужно выбрать тот, что большими буквами и в виде короткой записи.
на этом пока все. возможно еще подкорректирую статью, пост был важен для меня, так как при работе с проектом нужно было много разбираться и собирать по кусочкам. а что-то и самому изобретать. Надеюсь, статья будет полезна тем, кому необходимо решить аналогичный кейс.
В следующей статье напишу про то, как мы сделали веб страничку с сеансами пользователей и возможностью их удаления.
Веб авторизация доменного пользователя через nginx и HTTP Negotiate
Намедни встала задача — обеспечить прозрачную авторизацию пользователей домена в CRM, собственно Microsoft давным давно разработал для этих целей метод аутентификации HTTP Negotiate, это все замечательно работает на IIS и Windows Server, а у нас за плечами Samba4 в роли Primary Domain Controller и проксирующий веб сервер nginx. Как быть?
В сети куча информации по организации подобной схемы для Apache2 & AD на базе Windows, а вот пользователям nginx приходится собирать все по крупицам, информации кот наплакал. В базовой поставке Nginx нет подобного функционала. Благо люди не пали духом и история началась в мейл рассылках nginx в 2009 году, где один американский товарищ из Огайо нанял разработчика на RentACoder для запиливания модуля с подобным функционалом. Ребята форкнули подобный модуль для апача, прикрутили его к nginx и результаты работы выложили на github, где модуль время от времени допиливался разными людьми и в итоге принял роботоспособный вид. Последнюю версию можно получить на гитхабе.
В данном руководстве я расскажу как заставить работать nginx с SPNEGO модулем и samba4.
Первое необходимое — собрать nginx с нужным нам модулем. Для примера будет использоваться Ubuntu 16.04.
Для начала ставим nginx
Далее куда-нибудь качаем последнюю версию исходников с официального сайта.
Отлично, распакуем папку с исходниками и положим в него наш spnego-http-auth-nginx-module
Смотрим с какими опциями у нас сейчас собран nginx из базовой поставки и получаем портянку
Копируем в блокнот портянку и добавляем куда-нибудь
Приступаем к сборке с нужными нам параметрами
Естественно утилиты для сборки должны быть установлены в системе, а nginx должен быть потушен.
Для примера используем url для авторизации test.intranet.com, домен intranet.com
Пора немного поработать с самбой, добавим пользователя, на которого повесим service principal name (spn) для авторизации через Kerberos
Создадим Kerberos keytab файл для nginx
Проверим созданный keytab
Авторизуемся на контроллере домена через kerberos
Проверяем авторизацию в домене по имени spn с помощью keytab-файла:
У меня на данном этапе была проблема, аутентификация никак не хотела проходить. Ошибка:
kinit: Client not found in Kerberos database while getting initial credentials
Перерыл пол интернета, в итоге нашлось решение, оказалось samba-tool отрабатывает не так, как задумывалось Microsoft, неожиданно, правда? Для решения проблемы идем на виндовую машину и с помощью адмистративной консоли «Active Directory — пользователи и компьютеры» правим нашего пользователя HTTP, а именно правим поле имя входа пользователя на — HTTP/test.intranet.com После этой процедуры все работает.
Пора перейти к конфигурации nginx, смотрим мой конфиг виртуального хоста
Параметр auth_gss_allow_basic_fallback off; позволяет выключить запрос basic авторизации если пошло что-то не так, допустим юзер не в домене.
Остается немного допилить web приложение для прозрачной аутентификации, но то дело уже web программиста…
Доменная (LDAP) аутентификация в Codeigniter
Статья ориентирована на начинающих Codeigniter-щиков, таких как я.
В процессе создания внутреннего сайта одной из российских компаний, возникла необходимость ограничить доступ пользователей к некоторым страницам, функциям. Так как все пользователи в домене, то и на сайте есть смысл использовать доменную аутентификацию.
Найти самостоятельно информацию в принципе не трудно. Поисковые системы еще ни кто не отменял. Я просто решил собрать найденные кусочки и объединить их в один, на русском языке.
Допустим, что CI уже установлен и настроен. Кстати, на одном из западных сайтов, доступно много хороших и исчерпывающих видео уроков по настройке и использованию Codeigniter-а.
Добавим библиотеку и конфигурационный файл
Конечно, существуют некоторые функции в самом PHP, но использовать их не всегда рационально. За основу возьмем библиотеку adLDAP. В ней есть все необходимое и даже больше.
Первым делом создадим конфигурационный файл, например adldap.php и положим его в \system\application\config\
Далее необходимо добавить библиотеку. Но как сделать так, что бы ей можно было пользоваться в CI, как остальными? За нас это уже сделал один программист, и предоставил для общественного пользования (онутверждает, что лицензия не нарушена). Ее мы и добавим в \system\libraries\ и назовем, например Adldap.php.
После выше описанных манипуляций библиотекой можно пользоваться в Codeigniter-е, как и другими, например:
Напишем небольшой код авторизации
Сделать это проще простого. Во-первых, создадим форму для ввода логина и пароля:
Во-вторых, контролер и саму функцию для авторизации в домене. Но домен большой и пользователей много и если просто проверять пароль и логин, то к ограниченным частям сайта будут иметь все члены домена.
Для более тонкой настройки нужен еще один параметр для проверки — группа (Active Directory). Назовем ее, например Web_Group, и добавим нужных нам пользователей:
Вот и все. Теперь в любой другой функции можно делать проверку и в зависимости от результата предоставлять или не предоставлять доступ. Примерно это должно выглядеть так:
//Вытаскиваем и проверяем прошел или нет пользователь авторизацию if ($this->session->userdata(‘is_logged_in’) == true) <
echo «Доступ к данным открыт»;
Теперь осталось только дописать функцию уничтожения сессии (Logout):
function logout() < $this->session->sess_destroy(); redirect(); >
Примерная схема работы