Extra fields in LDAP
-
I'd like to initate a discussion regarding adding extra, custom fields to the Cloudron LDAP. Fields like description, phone number, public keys, wallet addresses, websites, geographic location are some examples.
The hope is for apps to be able to pull more information than the basics needed for authentication and names and that the Cloudron portal could serve even more as the central space for users to add and edit personal information as the app stack itself grows.
-
Generally this should be possible, but I don't see it as high priority at the moment. Maybe first we could see how many and which apps would even be capable of dealing with that.
@nebulon said in Extra fields in LDAP:
Generally this should be possible, but I don't see it as high priority at the moment. Maybe first we could see how many and which apps would even be capable of dealing with that.
Wordpress could easily support and Iād even make the necessary LDAP changes (and ask to merge them upstream) for that to happen.
-
Phone number(s) at least is handy for Mattermost and other apps where you can lookup by phone number(s), and some that use it as a 2FA option.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
Phone number(s) at least is handy for Mattermost and other apps where you can lookup by phone number(s), and some that use it as a 2FA option.
@marcusquinn We can use this thread to try to decide what
fieldsmake the most sense for whenever we want to add this feature to make the Cloudron directory more fleshed out. -
For app maintenance reasons it might be reasonable to predefine a bunch of fields but they way I imagined it was that every Cloudron admin would be able to extend the LDAP user database with more custom fields, each to their liking. At most Cloudron would provide field types for limiting input.
This way it would be up to the admins to integrate the additional information into the apps, as app compatibility and use case could vary drastically.
-
For app maintenance reasons it might be reasonable to predefine a bunch of fields but they way I imagined it was that every Cloudron admin would be able to extend the LDAP user database with more custom fields, each to their liking. At most Cloudron would provide field types for limiting input.
This way it would be up to the admins to integrate the additional information into the apps, as app compatibility and use case could vary drastically.
@yusf said in Extra fields in LDAP:
For app maintenance reasons it might be reasonable to predefine a bunch of fields but they way I imagined it was that every Cloudron admin would be able to extend the LDAP user database with more custom fields, each to their liking. At most Cloudron would provide field types for limiting input.
This way it would be up to the admins to integrate the additional information into the apps, as app compatibility and use case could vary drastically.
I love that, making it user customizable. Is that feasible, you people that know more about LDAP than I do?
-
The problem would not be so much on the LDAP side than on the app side : for a lot of apps, the LDAP config is overriden by cloudron on start to be set to the normal LDAP cloudron config, so I'm not sure how you could use such fields in the apps if they're not standard on Cloudron.
-
From a LDAP server perspective, it would be indeed quite easy to add more and even custom fields, however as @mehdi pointed out, this all comes down to integration with the apps. For example https://docs.bmc.com/docs/fpsc121/ldap-attributes-and-associated-fields-495323340.html holds a list of common attributes, which also are common on ActiveDirectory as far as I have seen. But looking at apps, I have not seen too many supporting them. So in order to not end up in some kind of mess, where we have to keep on patching upstream apps, I still kinda miss a collection of real use-cases. The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields.
Maybe @luckow can chime in here as well, since he has more experience with AD integration within organizations?
-
From a LDAP server perspective, it would be indeed quite easy to add more and even custom fields, however as @mehdi pointed out, this all comes down to integration with the apps. For example https://docs.bmc.com/docs/fpsc121/ldap-attributes-and-associated-fields-495323340.html holds a list of common attributes, which also are common on ActiveDirectory as far as I have seen. But looking at apps, I have not seen too many supporting them. So in order to not end up in some kind of mess, where we have to keep on patching upstream apps, I still kinda miss a collection of real use-cases. The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields.
Maybe @luckow can chime in here as well, since he has more experience with AD integration within organizations?
@nebulon said in Extra fields in LDAP:
The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields.
this also does not take into account that the free team edition of Mattermost (as packaged in Cloudron) does not use ldap at all.
-
@nebulon said in Extra fields in LDAP:
The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields.
this also does not take into account that the free team edition of Mattermost (as packaged in Cloudron) does not use ldap at all.
-
From a LDAP server perspective, it would be indeed quite easy to add more and even custom fields, however as @mehdi pointed out, this all comes down to integration with the apps. For example https://docs.bmc.com/docs/fpsc121/ldap-attributes-and-associated-fields-495323340.html holds a list of common attributes, which also are common on ActiveDirectory as far as I have seen. But looking at apps, I have not seen too many supporting them. So in order to not end up in some kind of mess, where we have to keep on patching upstream apps, I still kinda miss a collection of real use-cases. The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields.
Maybe @luckow can chime in here as well, since he has more experience with AD integration within organizations?
@nebulon said in Extra fields in LDAP:
The phonenumber for Mattermost is one such use-case, but that can be also solved without custom fields.
Assuming there might be a need for this in the future - what was the solution you thought of?
Also, even if app's don't use the fields, just having the Cloudron User directory more fleshed out might be a good thing for reference sake.
