Классификация объектов#
Классификация означает определение типа объекта (а именно вида и намерения) для объекта ресурса, который виден IDM.
Нормальный порядок действий заключается в том, что при первом обнаружении объект классифицируется. Однако существуют особые случаи, когда разрабатываются критерии классификации. Обычно проводится классификация и переклассификация объектов до тех пор, пока критерии не стабилизируются.
Общий алгоритм классификации следующий:
Сначала пробуются кандидатные типы объектов с указанным порядком классификации (
classificationOrderсвойство вdelineation). Первый подходящий тип используется.Затем пробуются кандидатные типы объектов без порядка. Соответствующие типы собираются.
Если среди совпадающих типов есть тип объекта по умолчанию («по умолчанию для класса объектов»), он используется.
Если существует ровно один соответствующий тип, он используется.
Если нет соответствующего типа, классификация не удалась.
Если существует несколько (не по умолчанию) совпадающих типов, выполняется специальная эвристика: возвращается первый из них с присутствующим разделом legacy
synchronization. В противном случае используется произвольный. (Это может измениться в будущем.)
Подробности можно увидеть в исходном коде.
Вот пример (искусственный) использования расширенной классификации типов ресурсных объектов.
Пример разграничения типов ресурсных объектов
<schemaHandling>
<objectType>
<kind>account</kind>
<intent>employee</intent>
<documentation>
Standard employee account. Resides in `employees` OU. Representative: `alice-employee.ldif`.
</documentation>
<delineation>
<objectClass>ri:inetOrgPerson</objectClass>
<baseContext>
<objectClass>ri:organizationalUnit</objectClass>
<filter>
<q:text>attributes/dn = "ou=employees,dc=example,dc=com"</q:text>
</filter>
</baseContext>
</delineation>
</objectType>
<objectType>
<kind>account</kind>
<intent>special</intent>
<documentation>
An account devoted to special duties. It resides in `special` OU.
This type is abstract, and has two subtypes: `admin` and `tester`.
</documentation>
<abstract>true</abstract>
<delineation>
<objectClass>ri:inetOrgPerson</objectClass>
<baseContext>
<objectClass>ri:organizationalUnit</objectClass>
<filter>
<q:text>attributes/dn = "ou=special,dc=example,dc=com"</q:text>
</filter>
</baseContext>
</delineation>
</objectType>
<objectType>
<kind>account</kind>
<intent>admin</intent>
<documentation>
Account used for administration. Resides in `special` OU (defined in the supertype).
Additional filtering condition: `businessCategory` is `admin`. Representative: `jim-admin.ldif`.
</documentation>
<super>
<kind>account</kind>
<intent>special</intent>
</super>
<delineation>
<!-- baseContext is inherited -->
<filter>
<q:text>attributes/businessCategory = "admin"</q:text>
</filter>
</delineation>
</objectType>
<objectType>
<kind>account</kind>
<intent>tester</intent>
<documentation>
Account used for testing. Resides in `special` OU (defined in the supertype).
Additional filtering condition: `businessCategory` is `tester`. Representative: `ann-tester.ldif`.
</documentation>
<super>
<kind>account</kind>
<intent>special</intent>
</super>
<delineation>
<!-- baseContext is inherited -->
<filter>
<q:text>attributes/businessCategory = "tester"</q:text>
</filter>
</delineation>
</objectType>
</schemaHandling>
Алиса, сотрудник
dn: uid=alice,ou=employees,dc=example,dc=com
uid: alice
cn: Alice Green
sn: Green
givenName: Alice
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
Джим, администратор
dn: uid=jim,ou=special,dc=example,dc=com
uid: jim
cn: Jim Admin
sn: Admin
givenName: Jim
businessCategory: admin
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
Энн, тестировщик
dn: uid=ann,ou=special,dc=example,dc=com
uid: ann
cn: Ann the Tester
sn: Tester
givenName: Ann
businessCategory: tester
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson