Support LDAP Property Mappings also for LDAP Provider in Outpost

[BobSilent]

Maybe I just did find it and this is more a question:

I wanted to extend the LDAP Provider in certain aspect

1. add an objectClass: posixAccount to returend users
2. change the return value of uid to be the User's username
3. add a new attribute gecos with the value of the User's name
4. add an 'calculated' attribute homeDirectory, which should be a combined string (base path) with the User's username

according to the description on the terminology page

Property Mappings

Property Mappings allow you to make information available for external applications. For example, if you want to login to AWS with authentik, you'd use Property Mappings to set the user's roles in AWS based on their group memberships in authentik.

I thought I could do it, like I already did it e.g. for the SAML Provider and "SAML Property Mapping" but for the LDAP Provider I cannot select any of these mappings.

The description in the Property Mappings

LDAP Property Mapping

LDAP Property Mappings are used when you define a LDAP Source. sounds different. states it differently and mentions the LDAP Source as the (only?) possibility to configure these Property mappings, so only when using and LDAP as Source not for LDAP as Provider in an Outpost.

At least from the "Property Mappings" Page I could not see that there is a difference between these mappings:

Describe the solution you'd like Like for SAML (or OAuth Scope Mappings? did not use it right now) I would like to be able to map custom configurations to LDAP Attributes or extend the LDAP functionality in order to provide this information to application.

Describe alternatives you've considered With some tricks I could adapt the LDAP client side with map_attribute in nss_ldap.conf but this is not always allowed, possible, well documented for client Apps. and it currently does not help me with 4. where I wanted to add a "calculated" value

[BeryJu]

Good point, it's not signaled very clearly which kinds of property mappings work in which direction.

For the actual feature, I thought about doing this in the past but chose not to, mainly since the LDAP outpost is already quite slow, adding more computation into the API calls it does is probably not a good idea.

I would still like to implement this at some point, when the go migration is happening/has happened (when I finally have enough energy to actually start that)

[BobSilent]

I have an addon for this, maybe this is more like a bug, but the requested feature here could help as well

The LDAP Provider (Outpost) also provides all authentik attributes like

goauthentik.io/ldap/active: true
goauthentik.io/user/service-account: true
goauthentik.io/ldap/superuser: false

but unfortunately is not possible to use them as e.g. filter via LDAP (or at least I was not able to do it), as . and / are special character which cannot (??) be used in attribute names for filtering. So with the mapping I could rename the attributes, as some (like service-account information or active status) are quite interesting for having them e.g. filtered out.

For the actual feature, I thought about doing this in the past but chose not to, mainly since the LDAP outpost is already quite slow, adding more computation into the API calls it does is probably not a good idea.

That's right and currently i would also prefer to get this faster with the ideas from #1946 Nevertheless i think that (however it gets implemented) could bring some flexibility for the LDAP usage (as it is still quite widely used)

I would still like to implement this at some point, when the go migration is happening/has happened (when I finally have enough energy to actually start that) Did I get you right, you plan to migrate from python to (more) go?

[Natanji]

I want to second that giving us at least very simple options to change the output of a few of these values would be very useful. However, I see complications.

For instance, the uid is most often simply a user's login name in the LDAP world and the assumption is that it's unique and unchangable. In authentik, that's completely different - all users can change their user name on their profile page (and I think there is no way for admins to disable that?). Imagine you use LDAP auth to log into an external service, it will probably use the uid attribute. When the user changes their name, they will no longer be able to login to tat service (e.g. Nextcloud would create a new user with that uid as its internal user id).

However, using the internal UUID of authentik is also problematic because many LDAP enabled apps assume it to be the actual login name. For instance, this is my user page in Jellyfin after logging into it via LDAP: Not really a helpful username. 🤣

It would thus be helpful if we could configure which attribute gets output to the uid field, but also, allow us to set that input field as immutable in the authentik admin panel to prevent our users from breaking things with it. Users can still change their display name.

[BobSilent]

@Natanji i know myself it is not the best, and what you are writting is really annoying also for me. And this reuqest here would really bring flexibility and the possibility to centrally preconfigure this in authentik instead of doing this in each and every application.

For instance, the uid is most often simply a user's login name in the LDAP world this is also for me the biggest pain (i would also say the default setting in authentik here is not the best choice)

But if this screenshot is still correct, you can try changing the LDAP Name Attribute from uid to cn.

I would assume this would already solve your issue with Jellyfin (which is also on my todo list 😉 ).

[BeryJu]

The statement about the speed is still valid, we map user attributes to LDAP attributes (as is stated on the website), however that could use some more documentation as it's currently described in a single sentence.

[gmoss-eschercloud]

I agree we have a few applications that don't allow you to change what attributes to use for the username and we are force to have really long uuid as the username's sometimes not even allowing to login due to that.

if we could have the mapping's supported in the provider it would allow for those small changes.

[Esheads]

+1