UserIdClaim



Система использует параметр UserIdClaim для определения атрибута пользователя из Keycloak, который автоматически подставляется вместо плейсхолдера {UserIdClaimValue} в поле UserFilter при поиске в LDAP.

UserIdClaim и UserFilter указываются в конфигурационном файле appsettings.json. Пример представлен ниже:

"OpenId": {
  "UserIdClaim": "email"
}
"Ldap": {
  "UserFilter": "(&(objectCategory=person)(objectClass=user)(userPrincipalName={UserIdClaimValue}))"
}

Здесь:

• UserIdClaim (в разделе OpenId) — указывает, какой claim из токена OpenID Connect будет использоваться при поиске пользователя.
• UserFilter (в разделе Ldap) — задает правило, по которому система будет искать человека в базе данных LDAP.

Как это работает на практике:

Если в Keycloak у пользователя в поле email указан адрес ivanov@company.ru, система автоматически возьмет его и подставит вместо {UserIdClaimValue}. В итоге LDAP получит готовый запрос:

(&(objectCategory=person)(objectClass=user)(userPrincipalName=ivanov@company.ru))

Внимание! Параметры UserIdClaim и UserFilter должны быть согласованы. Если в первом параметре вы указали поиск по email, то и в фильтре LDAP система должна искать совпадения по почтовым полям (например, userPrincipalName или mail).

UserIdClaim выполняет двойную роль:

• До LDAP-поиска — определяет, какое поле из токена взять как входное значение для фильтра.
• После LDAP-поиска — при наличии UserMatchAttribute, используется значение указанного атрибута LDAP-записи. В противном случае может использоваться значение UserIdClaim.

Однако в большинстве конфигураций с Active Directory идентификатором в Business Studio становится не само значение UserIdClaim, а атрибут LDAP-записи, указанный в UserMatchAttribute. Это сделано намеренно, т.к. почтовый адрес и логин могут меняться, а objectSid (стабильный уникальный идентификатор пользователя в AD) не изменяется при переименовании учётной записи.