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 12 Next »

 Тестовая среда для работы sso?

тест https://test.sso.corteos.ru/

продуктив https://prd.sso.corteos.ru/

 Какие поставщики удостоверений (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 код страны гражданства персоны. Является международным стандартом

 Обязательно ли передавать пол?

Да

 Обязательно ли передавать INN и KPP?

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

 Обязательно ли передавать дату рождения?

Да

 Если изменились данные по командировке, например, даты или направление поездки, а также данные пассажира, как обновить командировку в Кортеос?

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

<CustomOptions>
	<CustomOption>
		<Key>updateMode</Key>
		<Value>update</Value>
	</CustomOption>      
</CustomOptions>
 Можно ли без использования sso создание пользователя на лету создавать пользователя по sso создания новой командировки (данные по командируемому сотруднику отправляются и там и там одинаковые)?

Для создания пользователя в момент перехода можно только с помощью PersonToCreate в AccountDetails https://corteos.atlassian.net/l/cp/Qdh7C1R1

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

 Можно ли для начала тестирования создавать командировки без отправки данных по персональным кодам?

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

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

  • если кода нет, система смотрит наличие документов в запросе, если есть документы, то берет первый переданный и ищет по нему персону

  • если документов нет, то поиск персоны в системе происходит по переданным ФИО и дате рождения

 Правильно понимаю, что для создания командировки мы также не заполняем AccountDetails (указано как опциональные атрибут)

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

  • No labels