Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

 Тестовая среда для работы sso?
 Какие поставщики удостоверений (IdP) поддержаны в Corteos ?

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

 Если у клиента уже поддержана sso аутентификация например через Azure AD, то возможно ли будет использовать Azure AD и для входа в Corteos?

да, SAML 2.0. Необходим мод SSO (настройка sso saml) + в настройках темы домена задается спец. ссылка https://yourdomain.ru/mods/sso/AuthNRedirect/?redirectUrl=

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

Entity ID - ваш домен

Assertion Consumer URL - ссылка на sso

pass id_Group (в claims) - идентификатор группы

 Corteos может сам выступать в роли IdP ?

Нет

 В какой момент необходимо генерировать portalid (отправлять запрос Set)?

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

 Что будет если сгенерировать еще один portalid на те же даты на того же сотрудника?

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

 Коллбек необходимо отправить в систему, которая работает во внутренней сети

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

 Помимо русских ФИО, я должен ещё передать транслитерацию. По какому из стандартов необходимо транислитерировать?

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

  Можно ли вообще не передавать латинский вариант ФИО? Очень хотелось бы, чтобы это делалось автоматически на вашей стороне.

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

 В запросе есть параметр Gender="true". Почему в параметре пол проставляется флаг true или false? Какая здесь логика?

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

 DictionaryName="Табельный номер". Этот параметр всегда константный и всегда принимает значение "Табельный номер"? Или в разных случаях нужен разный набор для блока PersonalCodes? Если да, то просьба расписать эти сценарии

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

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

Если бы кто-то в задаче написал, какой агент и какой клиент, можно было бы посмотреть настройку этих словарей и дать скриншот со справочниками. Но кстати, Горовая Анна, тут ты по идее не хуже меня ориентируешься)

 В этом же тэге есть isPrimaryKey. В каких случаях он должен быть true, а в каких false?

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

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

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

 Email в тэге AccountDeatils - это email тревел-менеджера?

Это параметры пользователя, от имени которого будет вестись поиск и создаваться заказ. К сожалению, не знаю пдробностей интеграции, разные клиенты делают по-разному. Кто-то от имени ТМ создает заказы и всех передает пассажирами, а кто-то для каждого своего пользователя передает данные и создает уникального пользователя на нашей стороне.

 <sso:CountryAlpha2>RU</sso:CountryAlpha2> что за параметр? Он всегда константа?

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

  • No labels