Интеграция с IDM

Содержание

Интеграция с IDM#

Интеграция с IDM включает Global ERP в корпоративный контур управления учетными записями и доступами. Внешняя IDM-система инициирует операции над пользователями и доступами, а Global ERP принимает запросы напрямую или через интеграционный слой и применяет изменения средствами собственной модели безопасности.

Назначение интеграции#

IDM, или Identity Management, — это система централизованного управления учетными записями и доступами пользователей. В контуре Global ERP интеграция используется, чтобы операции с пользователями и доступами выполнялись по запросам из внешней корпоративной системы, а не вручную в интерфейсе Global ERP.

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

Global ERP не передает внешней системе прямое управление внутренней моделью безопасности. IDM передает команды и данные в согласованном формате, а Global ERP обрабатывает их через собственные объекты пользователей, профили доступа, роли и механизмы пересчета прав.

Роль Global ERP в интеграции#

Global ERP в IDM-контуре выступает прикладной системой, которая обрабатывает запросы на управление пользователями и их доступами. В базовой реализации запросы поступают напрямую через REST-интерфейс Global ERP. В адаптерных сценариях они могут передаваться через промежуточный компонент, например через корпоративную шину ESB.

Внутри системы Global ERP выполняет операции над собственными объектами: ищет пользователей, создает или изменяет учетные записи, назначает и отзывает доступы, блокирует пользователей и фиксирует результат обработки.

Объект

Назначение

Btk_User

Учетная запись пользователя Global ERP.

Bs_Person

Физическое лицо, связанное с пользователем.

Bts_ObjectContact

Контактные данные физического лица: email, рабочий телефон.

Btk_Group

Группа пользователя.

Btk_ObjectGroup

Связь пользователя с группой.

Btk_AcRole

Роль, которая может использоваться для сопоставления внешнего доступа с профилем Global ERP.

Btk_AcProfileGrant

Связь роли с профилем.

Btk_AcUserGrant

Назначение профиля пользователю.

Idm_RequestJournal

Записи обработки IDM-запросов.

Rpl_IntXmlInMsg

Интеграционное сообщение в контуре IDM.

На стороне IDM доступ может называться ресурсом, бизнес-ролью, ролью или профилем. В Global ERP такие внешние доступы не используются напрямую: перед настройкой интеграции они сопоставляются с моделью доступа Global ERP — профилями, ролями и правилами их назначения пользователям.

Общая схема интеграции#

Интеграция Global ERP с внешними IDM-системами включает базовую REST-реализацию и адаптерные сценарии для Avanpost IDM и Solar IDM. В адаптерных сценариях обмен выполняется не только средствами базового REST-интерфейса, но и через дополнительный компонент интеграции: адаптер внешней IDM-системы или корпоративную шину ESB. Разделы по адаптерам описывают отличия и проектные особенности интеграции с конкретными IDM-системами.

Для IDM-систем, которые не поддерживают формат запросов и ответов базовой реализации, требуются доработки или отдельный адаптер. В таком случае состав операций, правила сопоставления доступов и обработка отдельных endpoint-ов определяются требованиями конкретной интеграции.

В базовой реализации интеграция выполняется через REST-интерфейс Idm_ExchangePkg. Все операции выполняются как POST-запросы, тело запроса передается в формате JSON. В запросе указываются база и учетные данные пользователя, от имени которого выполняется вызов.

Путь вызова соответствует стандартной схеме REST-пакетов Global ERP:

<адрес базы>/app/sys/rest/ss/pkg/Idm_ExchangePkg/<endpoint>

REST-интерфейс базовой реализации покрывает основные этапы жизненного цикла учетной записи в Global ERP: поиск пользователя, создание или изменение учетной записи, управление доступами, блокировку и изменение учетных данных. Набор endpoint-ов зависит от сценария интеграции: IDM может использовать только назначение и отзыв доступов или полностью управлять созданием пользователей и их статусом.

Группа операций

Назначение

Поиск и чтение пользователей

Поиск пользователей, получение данных пользователя и статуса блокировки.

Управление пользователями

Создание пользователя и изменение данных пользователя.

Управление доступами

Получение доступов, назначение доступа пользователю и отзыв доступа.

Блокировка

Блокировка и разблокировка учетной записи.

Учетные данные

Изменение логина и пароля пользователя.

Контроль обработки

Фиксация запроса, результата обработки и ошибок.

Большинство операций ищет пользователя по логину: в запросе передается searchField = "login" и значение логина в searchValue. Для смены пароля используется поиск по uuid.

Пользователи, профили и доступы в базовой реализации#

Основная модель интеграции строится вокруг пользователя Global ERP, связанного физического лица, группы пользователя и профилей доступа. При обработке запросов IDM система не создает отдельную внешнюю модель доступа, а использует существующие объекты Global ERP: Btk_User, Bs_Person, Btk_Group, Btk_ObjectGroup, Btk_AcRole и связанные с ролями профили.

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

При создании пользователя Global ERP регистрирует учетную запись Btk_User, создает или находит физическое лицо Bs_Person по табельному номеру, связывает физическое лицо с пользователем и заполняет ФИО, email, внутренний телефон и группу пользователя. Если в запросе передан пароль, он устанавливается как временный.

Параметр userGroup используется для установки основной группы пользователя через Btk_Group и Btk_ObjectGroup. Если у пользователя уже были другие группы, метод оставляет новую группу как основную и удаляет остальные связи пользователя с группами. Для группы поддерживается формат с разделителем !!: первая часть используется как мнемокод группы, вторая — как отображаемое наименование.

В REST-интерфейсе IDM доступы передаются через параметр privCode. Значение privCode сопоставляется с кодом роли Btk_AcRole.sCode; роль синхронизируется с профилями через Btk_AcRoleApi.syncWithProfiles, после чего пользователю назначается соответствующий профиль через Btk_AcUserGrantApi.register. При отзыве доступа удаляются назначения профилей, связанных с переданными ролями.

Если в запросе на назначение или отзыв переданы коды ролей, которых нет в Btk_AcRole, они возвращаются в ответе в массиве exPrivCode. Это позволяет диагностировать расхождение между внешними доступами IDM и настройками доступа Global ERP.

Блокировка и учетные данные в базовой реализации#

Базовая реализация поддерживает получение статуса блокировки, блокировку и разблокировку пользователя. Статус передается через параметр isEmployeeLocked и соответствует признаку Btk_User.bNotActive.

Для блокировки пользователя вызывается endpoint lockUser с isEmployeeLocked = "true". Для разблокировки вызывается endpoint unlockUser с isEmployeeLocked = "false". После разблокировки Global ERP пересчитывает права пользователя. Если значение isEmployeeLocked не соответствует вызываемому endpoint-у, возвращается ошибка конфликта.

Endpoint changeUserLogin изменяет логин пользователя. Операция выполняется по текущему логину, а новый логин передается в параметре newValue. Перед изменением система проверяет, что пользователь с текущим логином существует, а новый логин не занят другим пользователем.

Endpoint changeUserPassword изменяет пароль пользователя по uuid. Переданный пароль устанавливается как временный, а при записи в RPL-сообщение значение password маскируется и заменяется на *****.

Контроль обработки в базовой реализации#

Каждый запрос обрабатывается через общий механизм: система проверяет права, фиксирует запрос, выполняет операцию, сохраняет результат и формирует HTTP-ответ. Перед выполнением целевой операции проверяется привилегия IDM через checkPriv("IDM").

Запросы фиксируются в Idm_RequestJournal. Запись создается в начале обработки, а после выполнения операции обновляется результатом или текстом ошибки. В записи сохраняются наименование запроса, тело запроса, результат обработки и сообщение об ошибке.

Дополнительно Global ERP пишет сообщение в интеграционный контур IDM через Rpl_IntXmlInMsgApi().createMessage. В сообщении фиксируются метод запроса, тело запроса, статус ответа и тело ответа. Если в теле запроса есть параметр password, при записи в RPL-сообщение его значение заменяется на *****.

Эти записи используются для диагностики интеграции: по ним можно проверить, поступил ли запрос от IDM, какой endpoint обрабатывался, какие данные были переданы и какой ответ вернула Global ERP.

Связь с LDAP-синхронизацией#

IDM-интеграция и LDAP-синхронизация решают разные задачи. IDM управляет предоставлением и отзывом доступа: инициирует создание пользователя, изменение данных, назначение доступа или блокировку учетной записи. LDAP, Active Directory или другой каталог может использоваться как источник доменных учетных записей, пользовательских атрибутов и данных для аутентификации.

При проектировании интеграции выбирается основной сценарий работы с доменом. Global ERP может работать с доменом напрямую через LDAP/AD-синхронизацию, загружать пользователей и применять настройки доступа средствами Global ERP. В другом сценарии работой с доменом и учетными данными занимается IDM-контур, а Global ERP принимает от IDM прикладные команды на создание пользователя, изменение данных, назначение или отзыв доступа и блокировку.

Допускается поэтапный ввод интеграции. Например, сначала пользователи загружаются в Global ERP из LDAP/AD и администрируются локально, затем подключается IDM. В этом случае IDM должен работать с теми же логинами, которые уже существуют в Global ERP; это позволяет избежать дублирования учетных записей.

В Global ERP LDAP-синхронизация реализована отдельным механизмом. Она позволяет загружать пользователей и доменные группы из корпоративного домена, сопоставлять их с учетными записями Global ERP, создавать или определять связанные объекты Bs_Person и Bs_Employee, обновлять пользовательские атрибуты и применять настройки доступа через шаблон нового пользователя или соответствия доменных групп с ОФС. Описание настройки LDAP-синхронизации приведено в разделе LDAP-синхронизация.

Важно не смешивать доменные группы и внутреннюю модель прав Global ERP. REST-интерфейс IDM работает с доступами Global ERP через согласованный формат обмена; доменные группы LDAP не являются прямым аналогом профилей или ролей Global ERP без отдельного сопоставления и настройки.

Требования и ограничения#

Перед настройкой интеграции фиксируется источник данных для каждого вида сведений: логина, табельного номера, физического лица, контактных данных, группы пользователя и доступов. Источников может быть несколько: кадровая система, домен или LDAP-каталог, IDM-система и Global ERP. Поэтому при обработке IDM-запросов в Global ERP уже могут существовать пользователь, физическое лицо или контактные данные, полученные из другого источника.

Для настройки интеграции фиксируются:

  • используемый сценарий интеграции: базовая REST-реализация или адаптерный сценарий;

  • адрес интеграционного endpoint-а или шины;

  • сервисная учетная запись для вызова интеграционных методов;

  • привилегии сервисной учетной записи;

  • перечень используемых операций;

  • обязательные параметры запросов;

  • источник логина;

  • источник табельного номера;

  • источник физического лица;

  • источник контактных данных;

  • правила сопоставления пользователей;

  • правила сопоставления внешних доступов с профилями, ролями или контекстами Global ERP.

Для базовой REST-реализации используется отдельная сервисная учетная запись с минимально необходимыми правами. Учетная запись должна иметь привилегию IDM, потому что перед выполнением операций Global ERP проверяет право на выполнение IDM-запросов. В адаптерных сценариях способ аутентификации и состав технических учетных записей определяются техническим решением конкретной интеграции.

При использовании интеграции учитываются следующие ограничения:

  • состав операций зависит от выбранного сценария интеграции;

  • в базовой REST-реализации большинство операций ищет пользователя по логину;

  • в базовой REST-реализации изменение пароля выполняется по uuid;

  • в базовой REST-реализации внешний доступ может передаваться через privCode, соответствующий Btk_AcRole.sCode;

  • в адаптерных сценариях формат передачи доступов может отличаться, например Solar IDM передает роли и контексты через методы ESB;

  • внешние профили, роли, ресурсы, контексты или группы IDM должны быть сопоставлены с моделью доступа Global ERP;

  • LDAP-синхронизация не заменяет IDM-интеграцию и не является тем же механизмом;

  • особенности адаптеров и проектные отличия описываются в отдельных разделах по конкретным IDM-системам.

Технические детали базовой реализации#

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

Расширение endpoint-ов#

В REST-интерфейсе IDM endpoint-ы регистрируются через карту mapMethods, где ключ — внутреннее имя обработчика, а значение — функция регистрации соответствующего REST endpoint-а. Затем карта передается в точку расширения Idm_Ept().updExchangeRestPath(mapMethods).

val rootPath: RestPath = RestPath { rpb =>
  val mapMethods: Map[String, RestPathBuilder => Unit] = Map(
    "postFindUser" -> postFindUser,
    "postGetUserData" -> postGetUserData,
    "postGetUserRights" -> postGetUserRights,
    "postGetAllRights" -> postGetAllRights,
    "postCreateUser" -> postCreateUser,
    "postAddUserRights" -> postAddUserRights,
    "postDeleteUserRights" -> postDeleteUserRights,
    "postChangeUserData" -> postChangeUserData,
    "postGetUserStatus" -> postGetUserStatus,
    "postLockUser" -> postLockUser,
    "postUnlockUser" -> postUnlockUser,
    "postChangeUserLogin" -> postChangeUserLogin,
    "postChangeUserPassword" -> postChangeUserPassword
  )

  for ((_, builder) <- Idm_Ept().updExchangeRestPath(mapMethods)) {
    builder(rpb)
  }
}

Механизм позволяет на проектных базах заменить обработку отдельных endpoint-ов и сохранить общий путь обращения к REST-интерфейсу. Внешняя IDM-система продолжает обращаться к согласованному endpoint-у, а Global ERP выполняет переопределенную логику.

Обработка и проверка запроса#

Каждый endpoint вызывает общий обработчик doWithCatchException. Он регистрирует запрос, проверяет привилегию, выполняет целевую функцию, сохраняет результат и фиксирует ошибку, если она возникла.

rpb("findUser").post { implicit request =>
  doWithCatchException(getJBodyObj, "findUser".ns) { jBodyObj =>
    ...
  }
}

Общая схема обработки:

  • создать предварительную запись в Idm_RequestJournal;

  • подготовить тело запроса для RPL-сообщения;

  • замаскировать password, если он есть в теле запроса;

  • проверить привилегию IDM;

  • выполнить функцию endpoint-а;

  • сохранить транзакцию;

  • обновить запись Idm_RequestJournal результатом обработки;

  • сформировать HTTP-ответ;

  • записать сообщение в интеграционный контур IDM.

Для большинства операций используется общий формат тела запроса с параметрами searchField и searchValue. Метод parseJBodyObjWithSearchField проверяет наличие тела запроса и обязательных параметров, затем передает нормализованное значение searchField и значение searchValue в функцию endpoint-а.

protected def parseJBodyObjWithSearchField(
  jBodyObj: JObject
)(f: (String, NString) => ResponseObj): ResponseObj = {
  if (jBodyObj.isEmpty) {
    ResponseObj(Response.Status.BAD_REQUEST, "Отсутствует тело запроса")
  } else if (!jBodyObj.contains("searchField") || !jBodyObj.contains("searchValue")) {
    ResponseObj(
      Response.Status.BAD_REQUEST,
      "Отсутствуют обязательные параметры: 'searchField' и 'searchValue' в теле запроса"
    )
  } else {
    f(jBodyObj.getNString("searchField").lower.get, jBodyObj.getNString("searchValue"))
  }
}

Поддерживаемые значения searchField: title, login, isEmployeeLocked, employeeNumber, uuid, privCode, privTitle. Каждый endpoint дополнительно проверяет, какие значения допустимы именно для него.

Для создания и изменения пользователя используется метод validateRequiredUserParam. Он проверяет наличие searchValue и employeeNumber, ищет пользователя по логину, физическое лицо по табельному номеру и определяет, не возникнет ли конфликт при создании или изменении данных.

Справочник endpoint-ов базовой реализации#

Все endpoint-ы базовой REST-реализации вызываются методом POST. Тело запроса передается в формате JSON.

findUser — поиск пользователей по ФИО, логину, статусу блокировки или табельному номеру. Возможные значения searchField: title, login, isEmployeeLocked, employeeNumber.

{
  "searchField": "login",
  "searchValue": "admin"
}

getUserData — получение расширенных данных пользователя по логину.

{
  "searchField": "login",
  "searchValue": "admin"
}

getUserRights — получение доступов пользователя по логину.

{
  "searchField": "login",
  "searchValue": "user_from_idm"
}

getAllRights — получение доступов, доступных для назначения через IDM-интерфейс. Если параметры поиска не переданы, endpoint возвращает список доступов. Поиск может выполняться по privCode или privTitle.

{
  "searchField": "privCode",
  "searchValue": ["Wf_DocAccess", "Bpm_TaskRole"]
}

createUser — создание пользователя, связанного физического лица, контактных данных и основной группы пользователя. Обязательные параметры: searchField, searchValue, employeeNumber.

{
  "searchField": "login",
  "searchValue": "user_from_idm",
  "employeeNumber": "123456",
  "lastName": "Иванов",
  "firstName": "Иван",
  "middleName": "Иванович",
  "userGroup": "Users",
  "email": "user@example.org",
  "internalPhoneNumber": "1234",
  "password": "temporaryPassword"
}

addUserRights — назначение доступа пользователю по кодам Btk_AcRole.sCode с последующим назначением соответствующих профилей.

{
  "searchField": "login",
  "searchValue": "user_from_idm",
  "privCode": ["Wf_DocAccess", "Bpm_TaskRole"]
}

deleteUserRights — отзыв доступа у пользователя по кодам Btk_AcRole.sCode.

{
  "searchField": "login",
  "searchValue": "user_from_idm",
  "privCode": ["Wf_DocAccess"]
}

changeUserData — изменение данных пользователя и связанного физического лица. Обязательные параметры: searchField, searchValue, employeeNumber.

{
  "searchField": "login",
  "searchValue": "user_from_idm",
  "employeeNumber": "123456",
  "lastName": "Петров",
  "firstName": "Петр",
  "middleName": "Петрович",
  "email": "petrov@example.org",
  "internalPhoneNumber": "5678"
}

getUserStatus — получение статуса блокировки пользователя по логину.

{
  "searchField": "login",
  "searchValue": "user_from_idm"
}

lockUser — блокировка пользователя.

{
  "searchField": "login",
  "searchValue": "user_from_idm",
  "isEmployeeLocked": "true"
}

unlockUser — разблокировка пользователя.

{
  "searchField": "login",
  "searchValue": "user_from_idm",
  "isEmployeeLocked": "false"
}

changeUserLogin — изменение логина пользователя.

{
  "searchField": "login",
  "searchValue": "user_from_idm",
  "newValue": "user_from_idm_new"
}

changeUserPassword — изменение пароля пользователя по uuid.

{
  "searchField": "uuid",
  "searchValue": "30151/123456",
  "password": "temporaryPassword"
}

Статусы ответов базовой реализации#

Базовая REST-реализация возвращает HTTP-статус и текстовое сообщение с результатом обработки запроса.

Статус

Когда используется

200 OK

Операция выполнена успешно.

201 Created

Пользователь создан.

400 Bad Request

Некорректный запрос, отсутствуют обязательные параметры или возникла прикладная ошибка обработки.

404 Not Found

Пользователь, роль или данные не найдены.

409 Conflict

Запрос конфликтует с текущим состоянием системы, например пользователь уже существует или передано некорректное значение статуса.

Ошибки AppException перехватываются общим обработчиком и возвращаются как Bad Request с текстом ошибки. Критические ошибки фиксируются в журнале, после чего исключение выбрасывается повторно.

Пример реализации Avanpost IDM#

Avanpost IDM использует адаптер под Global ERP. Адаптер обращается к REST-интерфейсу базовой реализации, поэтому операции с пользователями, доступами и статусами учетных записей выполняются без изменения внешнего контракта интеграции.

В реализации Avanpost IDM обмен инициирует внешняя IDM-система: на стороне Global ERP REST-интерфейс принимает запросы и формирует ответы. Формат обмена — JSON, транспорт — HTTPS или HTTP, для каждого метода выделяется отдельный URL, а аутентификация выполняется по Bearer-токену в заголовке Authorization.

В конкретной реализации могут добавляться проектные доработки: переопределение обработки отдельных endpoint-ов, дополнительные правила выбора группы пользователя, связь пользователя с проектными объектами, создание связанных записей и отправка уведомлений. Такие доработки относятся к проектному расширению базовой реализации и не являются обязательной частью общей интеграции.

Проектное переопределение endpoint-ов#

В реализации Avanpost IDM REST-интерфейс может дополняться проектной логикой через механизм расширения endpoint-ов Idm_Ept().updExchangeRestPath(mapMethods). Внешний IDM-контур продолжает обращаться к согласованному endpoint-у, а на проектной базе Global ERP выполняется расширенная обработка запроса.

Такой подход сохраняет общий адрес интеграции и позволяет добавлять проектное поведение: обработку группы пользователя, связь группы с внешним объектом, создание связанных записей и отправку уведомлений.

Проектные справочники и связи#

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

Такой справочник используется для сопоставления данных, приходящих из IDM, с объектами Global ERP. В зависимости от проекта в нем могут храниться код внешнего объекта, ссылка на объект Global ERP, признак активности, дата окончания использования или другие параметры, необходимые для обработки IDM-запроса.

Создание пользователей по проектной логике#

В общей логике создания пользователя параметр userGroup используется как код группы пользователей Global ERP. В проектном расширении значение группы может содержать дополнительный идентификатор, например код внешней организации, код группы во внешней IDM или другой признак, по которому Global ERP определяет группу пользователя.

Если группа определяется через проектный справочник или дополнительную связь, Global ERP ищет ее по проектным правилам. Если группа не найдена, проектная логика может создать ее автоматически, заполнить дополнительные признаки и затем создать пользователя в этой группе. Если значение userGroup не соответствует проектному формату, используется стандартная логика создания пользователя в группе по значению userGroup.

Создание связанных объектов#

При создании пользователя проектная логика может формировать дополнительные связанные объекты: связанную запись, ресурс или другой объект, который используется в проектных бизнес-процессах. Например, это применяется, если пользователь относится к внешней организации или контрагенту.

Такие объекты создаются по проектным правилам и не являются обязательной частью базовой реализации. Их состав, атрибуты и связи определяются требованиями конкретной интеграции.

Email-уведомления#

Проектное расширение может отправлять email-уведомления при создании пользователя, связанного объекта или выполнении другого значимого действия по IDM-запросу. Получатели определяются через проектные настройки, наборы значений, организационную структуру или другие правила внедрения.

Email берется из контактных данных физических лиц, связанных с получателями уведомления. Состав сообщения и ссылка на созданный объект определяются проектной логикой.

Пример реализации Solar IDM#

Интеграция с Solar IDM реализована как отдельный сценарий интеграции Global ERP с СУПД на базе Solar inRights. В этом сценарии внешний контур не обращается напрямую к REST-интерфейсу Idm_ExchangePkg: обмен выполняется через корпоративную шину ESB, которая принимает запросы СУПД, передает их в Global ERP и возвращает результат обработки в СУПД.

Global ERP в этой реализации выступает в двух ролях. Как источник данных система передает в СУПД сведения об учетных записях, ролях, контекстах и назначенных ролях с контекстами. Как приемник данных Global ERP обрабатывает управляющие воздействия из СУПД: создание учетной записи, изменение атрибутов пользователя, назначение и отзыв ролей, изменение контекстов ролей, блокировку и разблокировку учетной записи.

Схема обмена через ESB#

Обмен выполняется через корпоративную сервисную шину ESB. СУПД инициирует запрос, ESB передает его в Global ERP, Global ERP выполняет операцию или формирует выборку данных, после чего возвращает результат через ESB в СУПД.

Интеграция выполняется через REST JSON в асинхронном режиме по HTTPS. В синхронной сессии передается только подтверждение доставки сообщения. Результат выполнения операции возвращается позднее отдельным сообщением через callback endpoint. Для методов шины используются endpoint-ы вида:

/esb032/v2/<method>

Содержательные ответы и сообщения об ошибках передаются через callback endpoint:

/api/v2/messages

Для методов шины используются REST-запросы, асинхронный тип обмена, Basic-аутентификация и кодировка UTF-8.

Объекты доступа и контексты#

В реализации Solar IDM объектами доступа являются роли и контексты Global ERP. СУПД загружает эти объекты из Global ERP и использует их для управления назначениями пользователей. При назначении или отзыве доступа в Global ERP передаются роли и связанные с ними контексты, если они применяются для конкретного назначения.

Контексты уточняют область действия роли. Поэтому в этом сценарии синхронизируются список ролей, список контекстов и текущие назначения ролей и контекстов на учетных записях пользователей.

Операции интеграции#

В реализации Solar IDM используются отдельные методы шины для чтения данных из Global ERP и передачи управляющих воздействий в Global ERP.

Метод

Назначение

getUsers

Получение учетных записей пользователей Global ERP с назначенными ролями и контекстами.

getRoles

Получение объектов доступа типа «роль» из Global ERP.

getContexts

Получение объектов доступа типа «контекст» из Global ERP.

createUser

Создание учетной записи пользователя в Global ERP.

updateUser

Изменение атрибутов учетной записи пользователя в Global ERP.

disableUser

Блокировка учетной записи пользователя в Global ERP.

enableUser

Разблокировка учетной записи пользователя в Global ERP.

grantRoles

Назначение объектов доступа на учетную запись пользователя.

revokeRoles

Отзыв объектов доступа с учетной записи пользователя.

resetPassword

Сброс пароля учетной записи. Метод применяется для технических учетных записей без доменной авторизации.

Методы чтения используются для периодической загрузки данных из Global ERP в СУПД. Методы управления используются при событиях в СУПД: согласовании заявки на доступ, применении политики назначений, изменении кадровых данных, блокировке или разблокировке учетной записи.

Назначение и отзыв ролей#

При назначении доступа СУПД передает в Global ERP идентификатор пользователя и массив ролей. Для роли могут быть переданы контексты, которые должны действовать вместе с назначением. Global ERP обрабатывает запрос и назначает пользователю соответствующие объекты доступа.

При отзыве доступа СУПД передает идентификатор пользователя и роли, которые нужно отозвать. Если для роли используются контексты, в запросе также передается их состав. Global ERP применяет изменения и возвращает результат обработки через ESB.

Создание и изменение учетных записей#

Создание пользователя выполняется методом createUser. В запросе передаются идентификаторы пользователя, учетные данные и атрибуты, необходимые для создания учетной записи в Global ERP. Состав атрибутов зависит от требований интеграции и может включать логин, ФИО, email, должность, регион или другие данные пользователя.

Изменение данных пользователя выполняется методом updateUser. Он используется, когда в СУПД поступают изменения из внешнего источника кадровых данных или другого мастер-источника. После обработки запроса Global ERP обновляет атрибуты учетной записи и возвращает результат через ESB.

Блокировка и разблокировка#

Блокировка учетной записи выполняется методом disableUser, разблокировка — методом enableUser. Эти операции используются при увольнении, длительном отсутствии, изменении статуса сотрудника, согласовании заявки на блокировку или других событиях, которые требуют изменить доступ пользователя к Global ERP.

СУПД инициирует управляющее воздействие, ESB передает его в Global ERP, Global ERP изменяет состояние учетной записи и возвращает результат обработки в СУПД.

Сброс пароля#

Метод resetPassword используется для сброса пароля технических учетных записей, которые не используют доменную авторизацию. В запросе передается идентификатор пользователя и новый пароль. Пароль передается в зашифрованном виде.

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

Отличия от базовой реализации#

Реализация Solar IDM отличается от базовой REST-реализации тем, что внешний контур работает не напрямую с Idm_ExchangePkg, а через ESB.

Ключевые отличия сценария:

  • используются endpoint-ы шины, а не endpoint-ы Idm_ExchangePkg;

  • обмен выполняется в асинхронном режиме через REST JSON;

  • содержательный результат операции передается отдельным сообщением через callback endpoint;

  • доступы обрабатываются как роли и контексты;

  • структура сообщений и состав endpoint-ов определяются спецификацией Solar-интеграции.

Содержание