Настройка на MS AD осуществляется в конфигурационном файле sem-next.xml для варианта отдельного сервиса приложений, либо в настройках переменных yaml файла при развертывании сервисов платформы в k8.
<ActiveDirectory description="Определяет параметры подключения к Microsoft Active Directory">
<enabled description="Разрешена авторизация в MS AD">true</enabled>
<order description="0 - авторизации в MS AD, при неуспехе в InsparkIoT или 1 - авторизации в InsparkIoT, при неуспехе в MS AD">1
</order>
<url description="адрес подключения к MS AD">ldap://XX.XX.XX.XX:389</url>
<searchBase description="Вершина каталога от которой искать пользователей">
dc=portal,dc=cbr,dc=ru
</searchBase>
<user description="Пользователь для подключения к MS AD">
cn=melkartsync,cn=Users,dc=portal,dc=cbr,dc=ru
</user>
<password description="Пароль пользователя">****</password>
<principalSuffix description="Суффикс домена пользователя, если AD требует полного указания имени
пользователя.">@example_dns.com</principalSuffix>
</ActiveDirectory>
<order description> определяет порядок авторизации пользователя. Поддерживается вариант <MS AD- InsparkIoT>, в этом случае пользователь авторизуется сначала в MS AD и при неуспехе в InsparkIoT, и обратный вариант <InsparkIoT - MS AD>.principalSuffix обязательно указывать для всех версий MS AD.order 0 /order атрибуты пользователя синхронизируются со следующими полями в MS AD:| Атрибут | Поле InsparkIoT | Поле MS AD |
|---|---|---|
| login | Логин пользователя | sAMAccountName |
| firstname | Имя пользователя | givenName |
| lastname | Фамилия пользователя | sn |
| post | Должность | title |
| phone | Телефоны | telephoneNumber |
| Адрес электронной | ||
| state | Состояние | msDS-UserAccountDisabled |
| ilocale | Локаль | preferredLanguage |
| comment | Заметки о пользователе | displayName |
user_login@xx.exammple.comВ случае развертывания платформы в среде K8 , интеграци настраивается с помощью переменных файла yaml.
В стартовом файле value.yaml применены следующие значения переменных:
## 5. Настроить переменные приложения
## AD переменные
activedirectory:
enabled: false
url: ""
search_base: ""
## Вершина каталога от которой искать пользователей
user: ""
password: ""
suffix: ""
## Суффикс домена пользователя, не задавать если для входа будет использоваться полное
# имя входа (userPrincipalName ), в противном случаи задавать домен или его часть учетной записи пользователей.
# Например, для аутентификации пользователей из домена infsys.ru, чтобы пользователи вводили только имя входа, необходимо задать @infsys.ru.
# Например, для аутентификации пользователя в лесу Active Directiry из portal.cbr.ru и vip.cbr.ru, если searchBase задать dc=cbr,dc=ru
# и порт 3268, данный параметр необходимо задать .cbr.ru, тогда в качестве логина пользователя можно использовать часть userPrincipalName
# - semuser@portal, общая часть домена пользователя будет подставлена из параметра.
## включена ли отправка уведомлений
Значения переменных описано выше.
Для решения задач SSO, платформа Inspark подерживает протокол OAuth 2.0 как в варианте предоставления сервера аутентификации, так и в варианте клиента к стороннему серверу OAuth 2.0.
Ниже представлено описание настройки платформы для обоих случаев.
Данный вараинт предназначен для случаев, когда внешние системы являются клиентами OAuth сервера Inspark. При такой интеграции, при обращении к таким системам с учетной записью пользователя Inspark, внешние системы получают подтверждение о достоверности пользователя у платформы Inspark.
POST /oauth2/token
Входные параметры (все оязательные):
{"access_token": "string"}
Клиент должен быть известен. Текущий клиент должен быть авторизован, внутри проверяется сессионная кука.
GET /oauth2/authorize
Входные парамтеры:
Ответ:
В качестве результата метод выполняет редирект на redirectUrl, в качестве query параметров передает код запроса токена code и возвращает входящие CSRF (state).
В качестве авторизации используется токен доступа OAuth2
GET /oauth2/userinfo
Входные параметры:
Ответ:
{
«email»: «string»,
«user_name»: «string»,
«first_name»: «string»,
«last_name»: «string»
}
<auth>
<sessionTimeout>60</sessionTimeout>
<oauth2>
<!-- секретный код, который платформа подписывает JWT токены в формате Base64 -->
<jwtSecretKeyBase64>*******************</jwtSecretKeyBase64>
<!-- клиенты OAuth2 авторизации, платформа проверяет их при запросе токена авторизации -->
<client>
<id>inspark-superset</id>
<secret>**************</secret>
</client>
</oauth2>
</auth>
Важно! Секретный код задается в формате Base64 и для большей безопасности желательно чтобы этот Base64 был сгенерирован из набора байт, содержащих не печатные символы.
Пользователь логинится в Inspark IoT, и в этом же браузере он должен открыть ссылку интегрируемого сервиса, например Superset Apache.
Superset вызовет методы авторизации и получения информации о пользователе, и авторизует текущего пользователя Inspark IoT.
Если пользователь не будет логинится в Inspark IoT, а сразу попытается зайти на ссылку интегрируемого сервиса, вызовится панель авторизации Inspark IoT.
Для настройки на внешний сервер OAuth необходимо зайти в раздел меню Пользователи->Сервисы авториазации и создать запись на новый сервис. При заполнении полей нового сервиса указываются следующие данные:
| Поле | Назначение |
|---|---|
| Название | Название внешнего сервиса авторизации. Если не будет указана иконка для сервиса, то название будет выводится на форме логина |
| URL авторизации | URL предоставляется внешним сервисом авторизации, по сути это переход на страницу авторизации внешнего сервиса |
| URL токена пользователя | URL для получения токена пользователя. URL предоставляется внешним сервисом авторизации |
| URL информации о пользователе | URL для получения информации о пользователе. Некоторые сервисы авторизации его не поддерживают (например MS ADFS 2012). Если URL не задается, тогда вся информация о пользователе будет предоставляться из access token выдаваемого сервером после авторизации. В современных сервисах OAuth, в токене авторизации как правило задается только идентификатор пользователя, а дополнительная информация о пользователе предоставляется через заданный api (см. выше описание сервиса получения инфо о пользователе в Inspark /oauth2/userinfo) |
| ID клиента | идентификатор клиента платформы на сервере OAuth 2.0. |
| Секретный код клиента | Секретный код клиента (не обязательный параметр). Этот код выдается внешним сервисом OAuth |
| Базовый URL | Основной URL на платформу (RPT id),куда пользователь будет перенаправлен после авторизации. Для корректной работы, достаточно указать dns Имя сервера , например https://<имя сервера> |
| Публичный ключ | Публичный ключ для проверки подписи. Если в OAuth установлен сертификат с публичным и приватным ключом для подписывания выдаваемого access token, тогда сюда надо задать публичный ключ. Если ключ не задается, проверка подписи токена не проводится и доверяется как есть. |
| Имя, Фамилия, Отчество, e-mail | атрибуты пользователя, которые передаются от внешнего сервиса OAuth. Необходимо уточнить в OAuth сервисе наименование указанных полей, которые передаются либо сервисом информации о пользователе, либо при проверке токена. Для MS ADFS логин всегда содержится в атрибуте sub. |
| Права видимости | Информация от внешнего сервиса, если он поддерживает этот атрибут. Указываются права, с которыми пользователь обращается к OAuth сервису (необязательный атрибут) |
| Ресурс | Информация от внешнего сервиса (не обязательный атрибут) |
| Рубрика пользователей | Назначаемая по умолчанию рубрика для новых пользователей от OAuth сервиса |
| Группа пользователей | Ролевая группа пользователец для новых пользователей от OAuth сервиса |
| Цвет фона | Фон секции на странице логина внешнего сервиса авторизации |
| Логотип | Значок/ иконка внешнего сервиса авторизации |
Иногда, запрашивается Redirect URL (URL, на который будет перенаправлен пользователь после авторизации). Для информации, его структура будет вот такой: <Базовый URL>/sem-restservices/auth/oauth_callback
Все включенные внешние сервисы авторизации отображаются на первой странице логина. Пользователь выбирает требуемый сервис и при клике на секцию сервиса переходит на страницу логина внешнего сервиса. После ввода логина-пароля, внешний сервис редиректит (возвращает) информацию о пользователе платформе. Если в платформе такого пользователя нет, то создается новый пользователь с указанными правами доступа для этого сервиса.