OAuth 2.0

3 мая 2024 г.Около 3 минAdminSecuriyOAuth

Общие сведения

Для решения задач SSO, платформа Inspark подерживает протокол OAuth 2.0 как в варианте предоставления сервера аутентификации, так и в варианте клиента к стороннему серверу OAuth 2.0.
Ниже представлено описание настройки платформы для обоих случаев.

Настройка сервера аутентификации OAuth 2.0

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

RESTAPI методы

Получение токена

POST /oauth2/token
Входные параметры (все оязательные):

code: string, код для запроса токена авторизации
authorization: string, в http заголовке authorization передается авторизация с типом Basic в которой закодирован clientId:secret
Ответ:

{"access_token": "string"}

Код для запроса токена

Клиент должен быть известен. Текущий клиент должен быть авторизован, внутри проверяется сессионная кука.

GET /oauth2/authorize
Входные парамтеры:

client_id: string, обязательный параметр, идентификатор авторизумой системы, например, см. пример реализации OAuth интеграции с Apache Superset
redirect_uri: string, обязательный параметр, урл, на который следует выполнить редирект с ответом кода
scope: string, запрашиваемые разрешения (сейчас доступно только ‘userinfo’)
state: string, CSRF набор символов, будет возвращен в редиректе

Ответ:
В качестве результата метод выполняет редирект на redirectUrl, в качестве query параметров передает код запроса токена code и возвращает входящие CSRF (state).

Получение информации о пользователе

В качестве авторизации используется токен доступа OAuth2

GET /oauth2/userinfo
Входные параметры:

authorization: string, обязательный параметр, в http заголовке authorization передается авторизация с типом Bearer и токеном авторизации

Ответ:
{
"email": "string",
"user_name": "string",
"first_name": "string",
"last_name": "string"
}

Блок настройки в конфигурационном файле sem-next.xml

	<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 2.0

Подключение сервиса авторизации

Для настройки на внешний сервер 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

Как это работает

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