Долгие отношения с IDM Midpoint не могли пройти без последствий, так родилось это DEMO под названием EPPL - Employment Position Project LDAP. Как видно из названия это продолжение статей про концепцию Сотрудник Трудоустройства и Назначения на Должность в Midpoint. Но DEMO гораздо больше чем просто перенос кода, когда я описывал концепцию это был поиск, погоня за идей, которая местами уводила не в то место или просто что-то упускалось. В DEMO же во-первых все оттестировано(те функции что показаны ниже), найдена масса моих багов и к сожалению много переписано.. Комментировать код на этот раз не буду, но все что сделано-переделано отражено на окончательной схеме.
Проект IDM Midpoint DEMO EPPL на Github: IDM-Midpoint-DEMO-EPPL
Docker-образ: IDM-Midpoint-DEMO-EPPL/tree/main/Docker
Однако остаются и загадки, помимо найденных багов Evolveum - DEMO адаптировано под и протестирована на глюках версии 4.9.1, с глюками версии 4.9.2.-4.9.3 несовместима. Ни багами едиными, не во всех местах удалось Midpoint принудить к общечеловеческой логике... например если запрашивать на назначение одновременно роли которые требуют согласования и которые нет, то Midpoint ничего не выдаст без согласования той роли которой оно нужно, хотя мог бы выдать сразу те что не требуют. Тут главное не отчаиваться, какой-то смысл в это разработчики вкладывали же, значит где-то есть отключающие этот бред настройки, даже если они не задокументированы!
Функционал EPPL
1.Трудоустройства
- Создание/бликировка из HR источника
- Привязка к сотруднику из HR источника
- Создание из роли для трудоустройства роли для назначений
- Создание учеток в системах для трудоустройства
2.Назначения на должность
- Создание/блокировка из HR источника
- Привязка к трудоустройству из HR источника
- Запрос ролей на назначение
- Создание учеток в системах для назначений
3.Проект
- Создание и редактирование проекта сотрудником с ролью для создания проектов
- Добавление/удаление участников проекта
- Добавление/удаление прав проекта
- Создание специальных ролей под проект
- Давление специальных ролей под проект на участника проекта или на проект
- Отзыв специальных ролей под проект при удалении участника из проекта
- Отключение проекта с удалением из него всех участников
4. SOD
- Сценарии одобрения выдачи роли
- Ограничение возможности получения ролей по типу получателя и принадлежности к компании
5. Подчинённые
- Запрос прав на подчинённых
- Просмотр фото подчинённого
- Иерархическое определение начальников по отделам
6. Генерация логина/nickName
- Кириллица конвертируется в латиницу
- Генерируется в момент выдачи аккаунта
- Уникальность проверяется по name в Midpoint и в кэшах ресурсах
- Обновляется при изменении фамилии в HR ресурсе
- Логин освобождается если нет аккаунтов
7. Персональны данные
- Ограничение на просмотр
8. Подключённые ресурсы
- LDAP учетки/группы
- MS AD учетки/группы
- Создание Forward Roles из групп LDAP
- Создание Forward Roles из групп MS AD
- Создание Personal Data
- Экспорт фото в LDAP
- Создание Сотрудников\Трудоустройства\Назначений из HR источника(несколько ресурсов)
Не покупай возьми из Open Source
Главная цель DEMO показать IDM Midpoint вообще и функционал EPPL в работе. Поэтому буду описывать действия, в рамках выдуманной безымянной корпорации и её двух компании - EMP001001 (ООО «Один») без подключённого ресурса(MS AD настроено отключено, оказывает влияние через кэш) и EMP001002 (ООО «Дос») полноценно подключено к LDAP, который тут же в DEMO. В этих двух компаниях 30 людей с фото и личными данными (из них 28 сотрудников, 2 кандидата без трудоустройства), 29 трудоустройств, 31 назначений на должность... Не вдаваясь в код, все таки, надо сказать пару слов про внутренности.
Данные из HR источника
В EPPL ресурсы берут данные HR из csv файл через CSV Connector, это можно легко переделать на DB connector. В csv файле EPPL_HR_DATA.csv в папке /opt/midpoint/var/info все данные:
Основные
number_eppl - порядковый уникальный номер
type_eppl - тип записи
main_id - уникальный код, для User сотрудник это HR ID, (назначения начинаются с POS, трудоустройства с EMP)
parent_id - код организации (брать в ADMINISTRATION\Roles\Company Roles)
member_of_eppel - к кому относится, в единственном числе, для association в ресурсе
department_eppl - код отдела к которому относится назначение (брать в ADMINISTRATION\Org.structure\Department Caatalogs)
department_relation_eppl - если manager то начальник отдела, если нет то нет
status_eppl - статус, если надо кого то лишить назначения или трудоустройства меняем на disabled
Дальше просто данные.
Напомню в Midpoint можно запрашивать доступы только для User, User нельзя назначить другому User, а Role можно. Поэтому для трудоустройства, назначений мы создаем User для запросов доступов и Role для связи между ними.
Схематически это выглядит так
Подробно описывалось в первой статье про концепцию: Реализация концепции Сотрудник-Трудоустройство-Назначение на должность в IDM Midpoint part I
Как определяются начальники и подчинённые
Полностью отказался от использования orgRelation - главная причина в плане авторизации не даёт того что нужно, ну и не работает! В User назначение на должность в HR данных у нас написана принадлежность к отделу и тип принадлежности - начальник его или нет. Одно назначение один отдел - начальников на отделе может быть много из назначений, но в одном назначение один отдел. Все User назначения вешаются на отдел отношения default, отдел смотрит в назначенные User назначения у кого написано начальник и пишет в себя списком это мои начальники. Те кто в отделе не начальники пишут в себя из отдела это мои начальники. Начальники отдела пишут в себя начальников из следующего отдела. Вот так естественно и понятно у нас на каждом User назначении есть списком мои начальники и он легко запихивается во всякие авторизации.
Фото сотрудника
Есть в Midpoint встроенный атрибут jpegPhoto выглядит он как атрибут, прописан как атрибут, но не работает как атрибут. Есть обрывки тикетов указывающие на то что этот функционал надо самим дописывать в ядре... Но можно вкачать фото из ресурса, это работает. Но так как реализовано только возможность получать множество Shadow на один объект в Midpoint, а не множество объектов на одну шедов в одном ресурсе... короче. Сотрудник заходит в свой GUI как User сотрудник и хочет увидеть свою фото - увидит вкачаем из ресурса. Начальник хочет увидеть фото своего сотрудника - увидит сделаем из ресурса роль Персональные Данные, выдадим её назначению на должность сотрудника и дадим начальнику возможность смотреть в ней фото. Кстати этот костыль реализовал нам хранение и доступ к персональным данным - так как это еще одна Role можно конкретно тут авторизовать что видеть и кому, ну и писать в неё все что есть, даже то что не нужно для User сотрудник. Вернемся к фото, Midpoint хочет принимать фото только как текст, jpeg конвертируем в Base64 в линуксах командой: base64 -w 0 ./600667.jpg
SOD
В Midpoint SOD реализован скучно, нет отдельного меню, какой-то визуалки, да даже слова SOD нет в меню... однако продемонстрировать его работу можно! Добавим в пару ролей несовместимость с другими ролями. Тут главное помнить что пользователю для разруливания SOD конфликтов нужно давать на эти роль авторизацию не только на assign но и на unassign.
Одобрение тоже часть SOD и вот с ним гораздо интереснее возиться, в DEMO реализовано простенькое одобрение на Forward ролях есть riskLevel:
1 - назначает себе молча и начальник на подчинённого может это назначать
5 - сотрудник назначил себе ждет одобрение начальника прописанного в сотруднике, нет начальника не назначается отбой. Начальник назначил на сотрудника сразу одобрилось. Начальник назначил на себя сразу одобрилось. Тоже самое для снятия назначения.
6 - сотрудник назначил себе ждет одобрение начальника прописанного в роли, нет начальника не назначается отбой. Начальник из роли назначил на сотрудника сразу одобрилось. Начальник назначил на себя сразу одобрилось.
10 - начальник назначил на себя ждет одобрения вышестоящего начальника. Назначил но нет выше стоящего начальника - получает без одобрения. Назначил на себя не начальник сразу отказ.
DEP123456 - в riskLevel роли написано name отдела из которого брать начальников в одобрители. Нет начальников в отделе или нет отдела, отбой.
100 - одобряется administrator, автоматически назначается если запросил administrator. Это технический SOD для ролей выдающихся по реконсиляции или task (надо следить чтобы они тогда запускалиcь под administrator). Так же этот SOD назначается если riskLevel пусто или неизвестный.
Помимо это на запрашиваемых ролях висят политики(тоже SOD) не дающие их запрашивать/назначать, таким образом роль может быть:
- предназначена только для user с определённой компанией в назначениях
- предназначена для user определённого типа
- предназначено для user c проект ролью в назначениях
Вот так например выглядят assignment в роли максимально нагруженной SOD
Пароль
То что касается IDM и всего что рядом у Evolveum абсолютно не хватает скромности чего-то не пообещать. Вот только пароли - так и пишут используйте что-то еще. В рамках DEMO нам нужен пароль чтобы войти в GUI Midpoint, так что всем сотрудникам в User сотрудник накатим пароль «Password123». У User трудоустройства, User назначение, User аккаунт, User проект - пароля не будет. При создании учеток будет генерироваться какой-то пароль - дальше судьба этого пароль нас(IDM) не интересует в этом DEMO. В продуктиве примерно так и будет, даже еще круче мы вообще не будет думать о пароле в Midpoint потому что пользователи будут авторизовываться в Midpoint через связку с Keycloak, ну или будет перекачиваться пароль ресурсом из какой-нибудь одной системы.
ПЕРВЫЙ ЗАПУСК IDM Midpoint DEMO EPPL
После запуска IDM Midpoint DEMO EPPL Docker compose
Заходим под administrator
Url: http://localhost:8080/midpoint/
Login: administrator
Password: Test5ecr3t
Reindex Repository Object (ВАЖНО)
В ADMINISTRATION\About внизу нажать Reindex Repository Object
Подключаем LDAP
В ADMINISTRATION\Resources\All resources\LDAP EMP001002\Connector configuration заполняем атрибут Bind password с галочкой Use clear value. Midpoint скрывает пустые атрибуту, поэтому сначала внизу надо нажать Show empty fields и найти Bind password.
Password: Test5ecr3t
Нажимаем Save.
Нас выкидывает в список ресурсов, возвращаемся в ADMINISTRATION\Resources\All resources\LDAP EMP001002. Теперь на этом ресурсе вверху в правом квадранте есть Lifecycle state меняем там Archive на Active, он сам предлагает изменить сохранить. Будьте осторожны есть еще одно место где написано Lifecycle state в этом месте изменения игнорируются.
Нажимаем сверху ? Tets Connection
Создаём группы в LDAP
LDAP у нас пустой, но в Midpoint есть роли в которых роль EPPL Create LDAP Group from Role in EMP001002. Идем в ADMINISTRATION\Roles\LDAP Group roles выбираем все роли и нажимает Reconcile справа вверху под маленькой стрелкой вниз
У каждой роли должна появится 1 в Projections значит группа создана в LDAP
Можем посмотреть что в LDAP через phpLDAPadmin
Заходим
Login DN: cn=admin,dc=example,dc=com
Password: Test5ecr3t
Forward роли для групп в LDAP
Мы можем создать Forward роли в Midpoint из существующих групп в LDAP. Но они будут заполнены по умолчанию - а у нас уже есть FR роли под группы LDAP, и там заполнен riskLevel и прочее. Поэтому ресурс не будет их создавать, а просто привяжет оставив значения, можем и не привязывать, но для наглядности привяжем - в них обновиться Description с конкретным для этого свежего запуска entryUUID из LDAP. Кстати мы привязываемся по cn потому что его можно знать заранее а entryUUID нет.
Подключаем ресурс LDAP EMP001002 Forward Roles как до этого подключили LDAP EMP001002 и запускаем ADMINISTRATION\Resource\All resource\LDAP EMP001002 Forward Roles\Defined task\Recon
Смотрим в ADMINISTRATION\Roles\Forward Roles в поиске в name напишем LDAPG
Projections появились.
Реконсиляция персональных данных
Запускаем ADMINISTRATION\Resource\All resource\EPPL 00 Personal Data from HR DATA\Defined task\Recon PD по тексту будем все запускать вручную, но можно в каждом task прописать Schedule.
Идем в ADMINISTRATION\Roles\Personal Data
Тут создалось масса ролей со всеми доступными данными по людям.
Данные естественно все выдуманные, любое совпадение с реальностью случайно. Мы будем вешать эту роль на User назначение на должность, чтобы начальник смог посмотреть фото сотрудника, больше ничего ему не дадим видеть от сюда.
Реконсиляция данных из HR источника
Тут требуется серия реконсиляций
1. Запускаем ADMINISTRATION\Resource\All resource\EPPL 01 EMPLOYMENT Role\Defined task\01 EPPL Employment Role recon
Смотрим в ADMINISTRATION\Roles\Employment Roles
Роли трудоустройств создались но в них пусто
Нет связи с User сотрудник, неперекачено даже имя
2. Запускаем ADMINISTRATION\Resource\All resource\EPPL 01 EMPLOYMENT Role\Defined task\02 EPPL User
Смотрим в ADMINISTRATION\Users\Persons
Создались User сотрудники.
И смотрим на роль трудоустройство в ADMINISTRATION\Roles\Employment Roles
Имя пришло
3. Запускаем ADMINISTRATION\Resource\All resource\EPPL 02 EMPLOYMENT User + POSITIONS Role\Defined task\03 Recon Position as role
Смотрим в ADMINISTRATION\Roles\Position Roles
Роли назначение на должность созданы, тоже пока пустые, на следующем шаге привяжутся при создании User Трудоустройств и выкачают из него данные.
4. Запускаем ADMINISTRATION\Resource\All resource\EPPL 02 EMPLOYMENT User + POSITIONS Role\Defined task\04 Recon Employment as User
Смотрим в ADMINISTRATION\Users\Employment Users
Трудоустройства создались и заметьте к ним подтащилось имя, с самого верха, с User сотрудник.
5. Запускаем ADMINISTRATION\Resource\All resource\EPPL 03 POSITIONS USER\Defined task\05 Recon Position User
Смотрим в ADMINISTRATION\Users\Position Users
User назначения на должность созданы, если посмотрим внутрь
Тут уже масса информации и без доступов, потому что мы их еще не запрашивали конечно. Что-то пришло из ресурса, как например Title, имя пришло от User сотрудник, а Your Bosses пришло от департамента, потому что в assignment
User назначение уже привязан к:
Департаменту (получает из него список начальников в себя)
Компании (помимо прочего определяет какие роли можно назначать)
Персональным данным (чтобы начальник смотрел фото)
Роли Назначения (для связи)
Цепочка User сотрудник > Role трудоустройство > User трудоустройство > Role назначение > User назначение - выстроена!
ДЕМОНСТРАТИВНАЯ ЧАСТЬ IDM Midpoint DEMO EPPL
Повторяйте ниже описанные действия
Заходим в GUI Midpoint под User сотрудник
Url: http://localhost:8080/midpoint/
Login: 600740
Password: Password123
Пользователь начальник, так что сразу увидим максимально вкладок
Открываем ADMINISTRATION\Users\My IDM Users и видим наши активные объекты в IDM
Заходим в назначение на должность POS102298 в assignments
Видим что у нас на Position, то что определяет наши права
сверху в них.
- Отдел
- Организация
- просто роль с персональными данным(которые разрешено смотреть начальнику)
Запрос роли
Идем в Request access
Из-за особенностей GUI Midpoint все будут всегда видеть этот выбор, даже если нет проектов или подченных. Выбираем My Position
Выбираем единственное назначение
В каталоге ролей выбираем нашу организацию и Roles for Positions, в которой выбираем любую роль начинающеюся на [1] что значит она не требует согласования для получения
Нажимаем Add selected to cart и на Submit my request
Иназначение сразу получает роль. Это Forward Role она сообщает назначению и всей цепочки что у назначения должна быть такая-то LDAP группа. Сейчас её реально нет у работника, потому что нет аккаунта LDAP - это другая роль, запросим её.
В Request access\My Positions\ООО «Дос»\Roles for Positions выбираем роль [1] EMP001002 FR: Employment LDAP Account for Position. Есть еще роль [5] EMP001002 FR: Position LDAP Account она создает аккаунт на назначение, к логину добавляется «--1»(и т.д.), информация об LDAP группа не передаётся в Employment. Предпочтительно создавать аккаунт для Employment тогда он будет собирать LDAP группы со всех Position у которых нет аккаунта для LDAP.
Посмотрим на Position
Обе запрошенные Forwad Role(FR) получены, но моментально ничего не случилось. Мы тут касаемся Employment который связан с Position механизмами Links которые игнорируются при Request Access, поэтому все нужное сделает Server task максимум через минуту.
Идем в ADMINISTRATION\Users\My IDM Users
Появилось 600740 EMP002623 Employment LDAP Account это реальный User аккаунт который подключён к ресурсу LDAP. У него в assigment реальная роль LDAP группы
Смотрим на Full Name этого аккаунта написано:
LDAP login is:LIIma
Почему LIIma а не LIma? На пустом месте так бы и было первый вариант в генерации nickName это LIma. Но генерация nickName исключает совпадения:
- name в Midpoint
- cn в кэше аккаунтов ресурса LDAP EMP001002
- sAMAccountName в кэше аккаунтов ресурса Windows MS AD EMP001001
Ресурс MS AD у нас неподключен, заархирован, но в нем остался бессрочный(по задумке) кэш, а там есть учетка
Которая заняла nickName LIma и заставляет роль генерирующею nickName для аккаунта перебирать варианты дальше.
При создании аккаунта по FR роль для создания аккаунта, идет попытка прикрепиться к nickName роль для получения nickName, если её нет то она создается - так мы получаем nickName только тогда когда он нужен. Если у роли nickName нет членов Position, Employment то она удаляется через минуту и когда удалится кэш то nickName станет свободен. И мы специально проверяем по кэшу аккаунтов ресурса, чтобы не выкачивать их из ресурс, мало ли сколько там тысяч акканутов. Может возникнуть так что в кэше нет логина который есть в ресусре, но для этого мы и подняли IDM - теперь все аккаунты для системы создаём через IDM и кэш будет всё знать!
Идем в LDAP посмотрим что там
Любовь есть, хм а почему не видим в каких она группах...
...а в какой она группе видно в группе, чтобы узнать в какой группе пользователь надо знать в какой он группе... почему бы это сразу не показывать на самом пользователе?! LDAP прекрасен своей бесплатностью, а так конечно тот еще техномазохизм - впрочем это же можно и про Midpoint сказать!
Запрос роли требующей одобрение
Заходим под
Url: http://localhost:8080/midpoint/
Login: 600746
Password: Password123
В Request access\My Positions\ООО «Дос»\Roles for Positions запрашиваем роль [EMP001002] EMP001002 FR: GUI Personal Data Read. В квадратных скобках в начале написан код департамента, который должен начинаться на DEP, но может начинаться и на EMP это топ это начало всех департаментов компании - в любом случае одобрять будет начальник этого департамента, в данном случае самый главный.
То что эта роль будет назначена после одобрения в процессе запроса никак не афишируется. Только молча появляется Case в ADMINISTRATION\Cases\My Cases
Видно что мы что-то запросили на своё назначение - именно так, ни что ни у кого не видно! Так по умолчанию и видимо в этом есть какой-то смысл. Возможно этот вид можно доработать... А вот саму меню Cases не удалось доработать, показывать только My cases одну нельзя, только вместе с остальными... но ничего лишнего увидеть не удаться, на All request выдает ошибку потому что прав нет смотреть!
Идем в главного начальника
Login: 600038
Password: Password123
Тут уже нормально видно кто на кого что запросил в ADMINISTRATION\Cases\My work items
Можно тут сразу одобрить нажав на серую галочку справа, а можно зайти нажав на Name и одобрить на этой странице
Возвращаемся под
Login: 600746
Password: Password123
Вообще-то надо подождать не больше минуты пока все свершиться
Видим, появилась вкладка Roles, раньше её не было, а в ней Personal Data можем посмотреть всех.
Запрос роли с SOD
Заходим под
Url: http://localhost:8080/midpoint/
Login: 600746
Password: Password123
В Request access\My Positions\ООО «Дос»\Roles for Positions запрашиваем роли
[1] EMP001002 FR:LDAPG: BAR Coffee with chocolate и [1] EMP001002 FR:LDAPG: BAR Coffee with marshmallows обе [1] выдались молча без одобрения.
Теперь запросим роль [5] EMP001002 FR:LDAPG: BAR Tea
Еще не нажали Submit my request уже видим конфликты.
Заходим в Open conflict solver
Отказываемся от кофе ради чая
На роли [5] значит выдастся она после одобрения начальником.
Работа с проектами
Нам нужна роль [10] EMP001002 FR: GUI Project Manager - [10] значит её может запрашивать только начальник и в этом есть смысл потому что для проекта нужны подчиненные, кому его выдавать, и одобряется начальником начальника.
Заходим под
Url: http://localhost:8080/midpoint/
Login: 600740
Password: Password123
и запрашиваем её.
Заходим под
Url: http://localhost:8080/midpoint/
Login: 600733
Password: Password123
и одобряем её.
Через максимум минуту, заходим под 600740. Появляется вкладка ADMINISRATION\Roles а в ней My Projects
Нажимаем тут на портфель с плюсом и создаём первый проект
Тут в принципе ничего можно не заполнять, все данные потом можно будет редактировать, создатся проект с номер от 1 до 9999. Но всё-таки лучше заполнить.
Название проекта в - Identifier
Описание в - Description
Где лежат документы или почему создаётся в - Documentation
Active - автоматом поставится true
Employment - автоматом поставит EMP001002 код организации основного трудоустройства, его потом можно будет поменять но учтите что роли на проект можно запрашивать в той организации в назначении котрой был получен [10] EMP001002 FR: GUI Project Manager
Risk Level ставится 6 значит одобрять эту роль будут те кто указан в ней в User’ Boss ну и видеть запрашивать/выдавать будут тоже только они.
Запросим роли на проект
Идем в Request access\My Projects\ выбираем проект PRJ000001 идем дальше в ООО «Дос»\Roles for Projects и видим роли для проектов. Выбираем две
[DEP20201] EMP001002 FR:LDAPG: Knowledge Base Technical Support READ (одобрение не требуется потому что мы начальник DEP20201) и [1] EMP001002 FR:LDAPG: Meeting Room Mellifluous
Роли выдались, можно убедиться что точно да, для это надо перейти в Roles\My Projects\ PRJ000001\Members\PRJ000001\Assignments
Проект у нас и Role и User тут мы его видим как user, он числится в ООО «Дос» так что и проектные роли можно назначать только ООО «Дос»овские.
Запросим всем нашим подчиненным LDAP учетки
Подчинённых мы видим в Users\My IDM Subordinates
Идем в Request access\My Subordinates\ выбираем сразу всех
И в ООО «Дос»\Roles for Projects выбираем/запрашиваем им роль [1] EMP001002 FR: Employment LDAP Account for Position
Посмотрим получили они роль, на одном подчиненным, идем в Users\My IDM Subordinates600746 Р.Р.Ональдо IT Специалист в ООО "ДОС"\Assigments
Формально получили, это все что увидит начальника
Реально аккаунты будут созданы через максимум минуту когда отработает Server Task и их можно увидеть под administrator
Надо выдать себе и сотрудникам роль проект PRJ000001 идем в Request access\My Subordinates\ и в Request access\My Positions выбираем всех подчинённых и своё назначение и запрашиваем роль PRJ000001: Операторы колл центра ждем минуту и смотрим administrator
Реальные роли группы LDAP выдаются реальным учеткам
Убираем пользователя из проекта
Идем в Roles\My Projects\ PRJ000001\Members\ и отвязываем по одному, для отвязки пачкой нет прав. Нажимаем на значок перечёркнутой цепи справа от пользователя
Midpoint возмущается желтым(игнорируем), но отвязывает.
Создание и назначение специальных проектных ролей для проекта
Можно создать LDAP группу в название будет name проекта и еще что-то. Эти роли можно назначать на проект, а можно на назначения у которых есть роль проекта. Если назначение снимают с проекта то и все такие роли тоже уходят.
Идем в Request access\My Projects\ выбираем проект PRJ000001 идем дальше в ООО «Дос»\Roles for Projects и выбираем роли [1] EMP001002 FR:PRJ Creation of Forward Role for LDAP Group "[Project Name]-Data Edit" и [1] EMP001002 FR:PRJ Creation of Forward Role for LDAP Group "[Project Name]-Data Read"
Далее далее они молча выдаются и ничего заметного не случается, но вернёмся еще раз в Request access\My Projects\ выбираем проект PRJ000001 идем дальше в ООО «Дос»\Roles for Projects
Появились две новые роли [6] EMP001002 FR:PRJ for PRJ000001 LDAP Group PRJ000001-Data Edit и [6] EMP001002 FR:PRJ for PRJ000001 LDAP Group PRJ000001-Data Edit. Выдадим которая Read проекту пусть она будет у всех кто в проекте, а вот Edit выдадим одному только в проекте.
Идем в Request access\My Subordinates\ выбираем подчинённого у которого есть проект и идем в Roles for Positions
Тут зеленая галка что проект у него есть, выдаем ему [6] EMP001002 FR:PRJ for PRJ000001 LDAP Group PRJ000001-Data Edit смотрим на нем какие роли - те две про которые говорим есть, другие роли проекта мы тут не видим потому что это не аккаунт а назначение.
Теперь уберем его 600745 из проекта, как выше показывал и посмотрим что у него останется из ролей
Все правильно убрали из проекта, убралась роль проекта и роль которая назначалась только если у него была роль проекта. На аккаунте тоже все убралось естественно посмотрите под админом его аккаунт.
Закрытие проекта
Заходим в проект PRJ000001 и ставим Active в False
Сразу же у него поменялся статус и он пропал из Role Catalog как и роли созданные под него. Но Members еще есть в нем. Да и Midpoint если есть Members может ругнуться желтым - игнорируем - ждем не больше минуты когда сработает Server Task.
Все и Members пропали, проект теперь точно закрыт.
Кадровые события
У сотрудника 600740 поменялась фамилия была Има стало Обстер.
Соответственно меняем familyName в /opt/midpoint/var/info/EPPL_HR_DATA.csv строка 70 (по хорошему это надо делать каким-нибудь консольным редактором, а то например LibreOffice не терпит очень длинных строк в ячейках, а у нас фото на десятки килобайт там)
Реконсилим Resources\EPPL 01 EMPLOYMENT Role\Defined Tasks\02 EPPL User
Было
Стало
Смена названия компании
Идем под administrator в ADMINISTRATION\Roles\Company Roles\EMP001002 и меняем displayName на ООО «ТУ». Midpoint сильно призадумается.
Посмотрим на IDM объекты 600740 название компании в Full Name поменялось
И в Org в Role Catalog тоже изменится, а вот название головных Departaments нет - я этого не прописал.
Увольняем 600740 с назначения
В /opt/midpoint/var/info/EPPL_HR_DATA.csv строка 72 менеям status_eppl на disabled
Реконсилим Resources\EPPL 03 POSITIONS USER\Defined Tasks\05 Recon Position User
Было
Стало
Все запрашивал на назначение, назначение не активно все ушло!
Комплексный случай
Возьмём 600777 максимально в трудовом плане нагруженный сотрудник. Два трудоустройства три назначения на должность.
Аккаунт в MS AD у него уже есть (у меня, не в DEMO) так что роль nickName с логином уже сгенерирована и во всех остальных системах(LDAP) аккаунт для трудоустройства будет генерироваться с таким логином.
Заходим под сотрудником и запрашиваем роли в Request access\My Positions\POS102777\ООО «Дос»\Roles for Positions:
[1] EMP001002 FR: Employment LDAP Account for Position
[1] EMP001002 FR:LDAPG: BAR Coffee with chocolate
А в Request access\My Positions\POS102789\ООО «Дос»\Roles for Positions:
[1] EMP001002 FR:LDAPG: BAR Coffee with marshmallows
Смотрим
Аккаунт LDAP создан для трудоустройства с тем же логином что и для AD. И в нем собраны LDAP группы со всех двух назначений.
Теперь лишим его назначения POS102789
В /opt/midpoint/var/info/EPPL_HR_DATA.csv строка 90 менеям status_eppl на disabled
Реконсилим Resources\EPPL 03 POSITIONS USER\Defined Tasks\05 Recon Position User
Смотрим LDAP учетку
LDAP группа которая приходила с этим назначением ушла из LDAP учетки для трудоустройства.
Вернем обратно это назначение, чтобы группа вернулась.
В /opt/midpoint/var/info/EPPL_HR_DATA.csv строка 90 менеям status_eppl на active
Реконсилим Resources\EPPL 03 POSITIONS USER\Defined Tasks\05 Recon Position User
Запрашиваем под сотрудником в Request access\My Positions\POS102789\ООО «Дос»\Roles for Positions:
[5] EMP001002 FR: Position LDAP Account
SOD 5 значит назначение этой роли должен одобрит один из начальников отдела назначения POS102789 или 600740 или 600739. Ждем пока все свершится максимум до минуты.
Смотрим
Создалась еще одна LDAP учетка но уже для назначения, логин взят из nickName роли и добавлено --1 и так далее, если еще одному назначению выдать роль для аккаунта в этой системе на конце логина будет --2.
И так как у нас на назначение свой LDAP аккаунт группа LDAPG: BAR Coffee with marshmallows не пошла в учетку трудоустройства, а осталась на учетке назначения.
Фото сотрудников в четках LDAP
Можем фотки из ролей Personal Data экспортировать в учетки LDAP. Подключаем ресурс EPPL 99 Foto to LDAP как до этого подключили LDAP EMP001002 и запускаем Resources\EPPL 99 Foto to LDAP\Defined Tasks\Recon foto
Для этого ресурса настроено Multiaccounts, для того чтобы у одного объекта в Midpoint могло быть несколько Shadow в ресурсе - то что нам надо одна роль Personal Data имеет связь с несколькими Shadow аккаунтов в ресурсе LDAP для перекачки в них фото.
Глюки DEMO IDM Midpoint EPPL 1.0:
1. В авторизации в filter для RoleType не работает запрос A contains B если B это multivalue. Поэтому отказался от реализации много владельцев одного проекта. А с UserType этот же самый запрос работает, так что у назначений может быть несколько начальников.
2. При обновлении до следующей версии 4.9.4 проверяем в Request Aceess видно ли свои или подчинённых Position. В 4.9.2,4.9.3 поломано Fatal error.
3. Не глюк а особенность... Если мы запрашиваем роль через Request Aceess механизмы Links игнорируются и нам нужен Server Tasks чтобы пропихнуть изменения. А когда мы редактируем проект, механизмы Links пытаются выполниться, но нам это не нужно, потому что тогда сотруднику надо прописывать авторизацию на всё что нужно сделать дальше. При этом редактирование случается и изменения будут пропихнуты Server Tasks’ом, но сотрудник видит желтое предупреждение о нехватке прав на каком-то из дальнейших шагов, что конечно будет смущать и пугать! Тут надо или как-то находить настройки чтобы отключать в этом месте и случае предупреждение или выдавать мега авторизацию! В User аккаунт не пишется начальник, а то можно было попытаться настроить конкретную авторизацию, и тогда надо писать со всех назначений начальников!
Вот так можно быстро, а главное просто, начать работать с трудоустройствамии назначаениями в Midpoint!