Currently, SSO configuration supports a limited set of claims:
- Subject
- Username
- Phone
- Email
- Display name
- Groups
In our infrastructure, additional user information such as Slack ID and Telegram ID is already stored in LDAP attributes that are not normally used for this purpose (e.g. pager, employeeNumber).
Keycloak can expose these attributes as custom OIDC claims, for example:
{
"slack_id": "U0123456789",
"telegram_id": "123456789"
}
However, IncidentRelay currently has no way to map these claims to the corresponding user fields.
It would be useful to support optional custom claim mapping, for example:
Slack ID → slack_id
Telegram ID → telegram_id
Ideally, this could be implemented as a generic IncidentRelay field → OIDC claim mapping, rather than hard-coding specific claims.
This would allow organizations to reuse existing identity data without introducing an additional user synchronization mechanism.
Currently, SSO configuration supports a limited set of claims:
In our infrastructure, additional user information such as Slack ID and Telegram ID is already stored in LDAP attributes that are not normally used for this purpose (e.g. pager, employeeNumber).
Keycloak can expose these attributes as custom OIDC claims, for example:
However, IncidentRelay currently has no way to map these claims to the corresponding user fields.
It would be useful to support optional custom claim mapping, for example:
Slack ID → slack_id
Telegram ID → telegram_id
Ideally, this could be implemented as a generic IncidentRelay field → OIDC claim mapping, rather than hard-coding specific claims.
This would allow organizations to reuse existing identity data without introducing an additional user synchronization mechanism.