Custom attribute from directory to token

I want to implement an application that allows to order a service based on the room an employ is working at. Fortunately, my directory provides an attribute roomNumber that I can leverage. But it is not clear to me, how to configure Keycloak accordingly to import, display, and map the attribute to the token.

I started with defining a mapper to import roomNumber, but unfortunately the attribute is not shown in Keycloak when displaying a user, and I also cannot search using that attribute. Is it possible to display additional attributes?

And then, how does one add additional attributes to a token?

You need to give more information, as there are so many ways to achieve that in keycloak.

So the kc version, configured options, type of federation etc are needed.

For ldap/ad a user-attribute-ldap-mapper would be the right choice here. And this should also show up in the user ( tab ‘Attributes’)

26.3.2

Configured options like this?

Enabled features

ACCOUNT_API

Supported

ACCOUNT_V3

Supported

ADMIN_API

Supported

ADMIN_FINE_GRAINED_AUTHZ_V2

Supported

ADMIN_V2

Supported

AUTHORIZATION

Supported

CIBA

Supported

CLIENT_POLICIES

Supported

DEVICE_FLOW

Supported

HOSTNAME_V2

Supported

IMPERSONATION

Supported

KERBEROS

Supported

LOGIN_V2

Supported

OPENTELEMETRY

Supported

ORGANIZATION

Supported

PAR

Supported

PERSISTENT_USER_SESSIONS

Supported

RECOVERY_CODES

Supported

ROLLING_UPDATES_V1

Supported

STEP_UP_AUTHENTICATION

Supported

TOKEN_EXCHANGE_STANDARD_V2

Supported

USER_EVENT_METRICS

Supported

WEB_AUTHN

Supported

Disabled features

ADMIN_FINE_GRAINED_AUTHZ

Preview

CLIENT_SECRET_ROTATION

Preview

CLIENT_TYPES

Experimental

CLUSTERLESS

Experimental

DECLARATIVE_UI

Experimental

DOCKER

Supported

DPOP

Preview

DYNAMIC_SCOPES

Experimental

FIPS

Supported

INSTAGRAM_BROKER

Deprecated

IPA_TUURA_FEDERATION

Experimental

LOGIN_V1

Deprecated

LOGOUT_ALL_SESSIONS_V1

Deprecated

MULTI_SITE

Supported

OID4VC_VCI

Experimental

PASSKEYS

Preview

QUICK_THEME

Experimental

ROLLING_UPDATES_V2

Preview

SCRIPTS

Preview

TOKEN_EXCHANGE

Preview

TOKEN_EXCHANGE_EXTERNAL_INTERNAL_V2

Experimental

TRANSIENT_USERS

Experimental

UPDATE_EMAIL

Preview

Federation: I am using LDAP with active directory and kerberos authentication.

What else?

I defined a user-attribute-ldap-mapper for the attribute, but I cannot see the attribute when looking at a user for which I know the attribute exists.

did you also reimport the user(s)? Everything isfrom ldap/ad is only updated on synsc, not on login etc.

Thanks for following up!

I was assuming „Always Read Value From LDAP“ doesn´t require syncing. After syncing the attribute shows up on user General below names, not on tab Attributes as you indicated.

After mapping this attribute with a token mapper I get something like the following in my authorization cookie:

“myvalue”: [“X”, “Y”],
“email”: “joachim@example.com”,

i.e. the attribute is on same level then identity attributes. I was expecting this under some other path like „resource_access“ (I ticked both „Add to access token“ and „Add to lightweight access token“ but not „Add to userinfo“).

You can probably not see the user attribute, as you have to create proper attribute in the user profile (Realm settings → User profile tab).
Just because you map an attribute from LDAP to Keycloak, it’s not automatically a managed attribute.
Mapping the attribute from the user attributes to the tokens isn’t affected from the user profile attributes, this should work either way. But being able to see the attribute at the user is probably a good first step to “debug” your environment, or being able to find out more about your issue.

Actually I created two attributes, one with just mapping, the other within realm settings, and I didn´t experience any difference so far. Can you please elaborate on the difference of a “managed attbribute” and a “mapped attribute”?
As I wrote above, I can see the attribute on the keycload UI but in a different location than Björn wrote and in the token in a different location than I´d expect.