Часто задаваемые вопросы

Поддерживается сам протокол SAML 2.0, если он реализован у поставщика, то доработок не потребуется. Единственные моменты, которые требуются, это возможность настройки параметров подписи и передачи сертификата шифрования (нам они нужны) и custom claims, иначе потребуется доработка

да, SAML 2.0. Необходимо включить мод SSO и настроить sso saml. Также в настройках темы домена задать ссылку на SSO редирект - для перенаправления на нее пользователя при входе или выходе из системы.

На стороне SSO портала Кортеос в настройках указываются:

user redirect link - ссылка, куда пользователь будет переадресован после успешного входа. Это ссылка вида https://yourdomain.ru/Mods/SSOEntrance/Go, где yourdomain.ru – ваш домен
Serial Number - серийный номер из сертификата (в верхнем регистре). Серийный номер сравнивается с серийным номером из сертификата в запросах.

На стороне AD в настройках указываются:

Identifier (Entity ID) - ваш домен
Reply URL (Assertion Consumer Service URL) - ссылка на SSO портал (для теста https://test.sso.corteos.ru/SamlAuth, для прода https://prd.sso.corteos.ru/SamlAuth)
pass id_Group (в claims) - Идентификатор группы компаний клиента для API

Нет

При каждом переходе, у portalid срок жизни - 10 минут

Ничего не будет, portalid действителен пока не пройдет 10 минут

Необходимо захостить брокер сообщений(например, rabbitmq), а внутренняя система сможет из него забирать сообщения

Можно по таким правилам https://transliteration.pro/zagranpasport

Да, мы автоматически это делаем, если что-то не передается. Не всегда написание в паспорте соответствует автоматической транслитерации, и для таких случаем есть возможность передавать нужные значения

true = мужской, false = женский

Берутся названия словарей и коды, прикрепляемые к персоне.

Это определяется интеграционной логикой и настройками, которые выполняет агентство

К персоне может быть привязано несколько кодов из разных справочников. Например, Табельный номер (это может быть идентификатор в учетной системе клиента), Категория должности (для применения тревел-потилики) и т.п.

Данное значение обязательно должно быть уникальным.

Ключ isPrimaryKey = true позволяет определить, какой код отвечает за идентификатор пользователя. По этому параметру синхронизуются данные из запроса с данными в БД и обновляются значениями, передаваемыми в запросе.

Если такого параметра нет, то мы пробуем искать по документу, а потом по ФИО + ДР. Если никто не нашелся, создаем нового.

Это параметры пользователя, от имени которого будет вестись поиск и создаваться командировка

Это ISO-2 код страны гражданства персоны. Является международным стандартом.

Если данный параметр не будет передан, то персоне проставится гражданство Российской Федерации.

Да

Нет, если не будет передано, то персона привяжется к первой найденной организации

Да

Необходимо осуществить повторный переход в Кортеос, для обновления данных по командировке передать спецфлаг

					<sso:CustomOption>
						<sso:Key>updateMode</sso:Key>
						<sso:Value>update</sso:Value>
					</sso:CustomOption>

Создание пользователя в момент перехода можно только с помощью PersonToCreate в AccountDetails SSO: создание пользователя на лету

Но пользователей можно создавать и через Api: Orchestrated API или простой CRUD , тогда можно не создавать пользователя на лету

Можно, но опишем как работает определение пассажира:

система смотрит наличие структурного кода с флагом IsPrimaryKey="true" - если такой есть, то поиск персоны происходит по привязке к этому коду. Подразумевается, что код уникальный, например, табельный номер
если кода нет, система смотрит наличие документов в запросе, если есть документы, то берет первый переданный и ищет по нему персону
если документов нет, то поиск персоны в системе происходит по переданным ФИО и дате рождения

Необходимо заполнять, id_Group, GroupSecurityKey - необходимы для авторизации, корректного поиска\создания персон и командировок. Email - это пользователь инициатор(создатель) командировки

Блок <sso:CurrentRoute> обязателен. На основе этого блока строится маршрут и автозаполнение на форме поиска. На основе данных в блоке <sso:CustomRoute>фиксируются даты в календаре. Если ограничения по датам нет, то блок <sso:CustomRoute>можно пропустить.

На данный момент Мод с мягким сохранением структуры маршрута не совместим с Модом “Интеграция по SSO”, так как не умеет работать с сегментами маршрута командировки, создаваемого через SSO. Более подробно о Моде можно узнать тут.

Мод с жестким сохранением структуры маршрута адаптирован к SSO. Более подробно об особенностях создания командировки с этим Модом можно узнать тут.

При использовании SAML переход в систему Corteos возможен только для зарегистрированных пользователей.

Как проверяется наличие пользователя из запроса перехода:

1) корректный email пользователя необходимо передавать в NameID (и пользователь должен существовать в договоре)
2) можно email передавать через claims "mail". Но тогда его не надо передавать в NameID

Т.е. это работает так:

смотрим email в NameID, если в NameID указана почта, дальше не смотрим
если в NameID не указана почта, смотрим claims "mail"
Если ни одна из почт не найдена, то пользователю будет выдана ошибка доступа.
если нельзя сделать связку с почтой, NameID должен совпадать с каким-то уникальным структурным кодом.

Этому нет никаких препятствий

Нет, функционала замены пассажира командировки - не существует. При попытке добавления пассажира, используя функцию “updateMode” у вас добавится новый пассажир, при этом старый останется в командировке.

<sso:CustomOption>
						<sso:Key>updateMode</sso:Key>
						<sso:Value>update</sso:Value>
					</sso:CustomOption>

После получения corteosID пользователь может воспользоваться этой ссылкой для перехода на платформу в течение 10 мин.

OuterID не может превышать 50 символов. OuterID состоит из непосредственно внешнего номера клиента и системной информации о договоре, которая занимает 6 символов. Поэтому в запросе нельзя передавать более 44 символов. В случае превышения количества символов будет возвращена ошибка с информацией о том, что поле слишком длинное.
OuterID должен быть уникальным для каждой командировки.