Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification Needed on Required Permissions for LDAP User in CT with v3 Wrapper #53

Open
sebamomann opened this issue Dec 20, 2024 · 4 comments

Comments

@sebamomann
Copy link

Hi,

First off, thank you for the amazing work on this wrapper — I'm very happy with it!

Recently, after someone accidentally deleted our LDAP user in CT, I decided to take the opportunity to upgrade to v3 of your wrapper. However, I encountered some challenges regarding the required permissions for the LDAP user.

Following the principle of least privilege, I aimed to grant only the minimal permissions necessary for functionality. Unfortunately, determining the exact set of permissions has been quite tedious, largely due to the complexity of CT's permission system.

Additionally, I noticed something concerning:

If I successfully log in via LDAP with any CT user, then remove some of the permissions from the LDAP CT user (CT_USER) for testing, I can still log in via LDAP with any CT user. This behavior suggests there might be some form of caching involved.
Could you please clarify the exact permissions required for the LDAP user in CT (CT_USER) to function correctly with v3? I wasn’t able to find this information in the documentation.

Thank you for your assistance!

@svenwanzenried
Copy link

I'm also very interested in an guideline, which permissions are needed exactly.

@sebamomann regarding the caching. There is an environment variable CACHE_LIFETIME_MS which is set to 300000 by default. This means cache is 5 minutes.

@milux
Copy link
Owner

milux commented Feb 26, 2025

@sebamomann regarding the caching. There is an environment variable CACHE_LIFETIME_MS which is set to 300000 by default. This means cache is 5 minutes.

This is correct, BUT it doesn't apply to authentication. Auth is always done against the REST API directly, since the hashed passwords cannot be queried anyway and are therefore out of scope.
Caching applies only for users, groups and their respective relations.

@svenwanzenried
Copy link

Thanks for the clarification.
Can you provide any clarification regarding the permissions needed in churchtools?

@milux
Copy link
Owner

milux commented Feb 26, 2025

Regarding the overall issue:
To be honest, I can only tell you with certainty which REST calls the tool performs against the ChurchTools API:
GET /groups/members (mappings of persons/groups)
GET /person/masterdata (group types for LDAP object classes)
GET /persons
GET /groups
POST /login (for auth, obviously, body contains auth JSON)
API documentation is available at https://your-church.church.tools/api.

The precise set of privileges required for these API calls to work depends on the code of ChurchTools and (at least partially) the structure of your church's data in CT.

These are the privileges I use for the API user, without any guarantee whatsoever about being the minimal viable set:

Image

Image

Maybe that helps.
I keep this issue open in case someone wants to contribute a precise documentation based on the CT code or trial-and-error experiments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants