Add ldap authentication

[skbhagat0502]

What kind of change does this PR introduce?

A feature request.

Issue Number:

Fixes #1070

Did you add tests for your changes?

Yes

Snapshots/Videos:

If relevant, did you update the documentation?

Summary

Added the ldap authentication method.

Does this PR introduce a breaking change?

Other information

Have you read the contributing guide?

[github-actions]

Our Pull Request Approval Process

We have these basic policies to make the approval process smoother for our volunteer team.

Testing Your Code

Please make sure your code passes all tests. Our test code coverage system will fail if these conditions occur:

1. The overall code coverage drops below the target threshold of the repository
2. Any file in the pull request has code coverage levels below the repository threshold
3. Merge conflicts

The process helps maintain the overall reliability of the code base and is a prerequisite for getting your PR approved. Assigned reviewers regularly review the PR queue and tend to focus on PRs that are passing.

Reviewers

When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

1. PRs with issues not assigned to you will be closed by the reviewer
2. Fix the first comment in the PR so that each issue listed automatically closes

Other

1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
2. Read the CONTRIBUTING.md file make

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (29b87a9) 91.85% compared to head (8da7da0) 91.90%.
Report is 54 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1077      +/-   ##
===========================================
+ Coverage    91.85%   91.90%   +0.05%     
===========================================
  Files          133      134       +1     
  Lines         3227     3248      +21     
  Branches       905      905              
===========================================
+ Hits          2964     2985      +21     
  Misses         254      254              
  Partials         9        9              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[skbhagat0502]

2023-11-20.21-08-14.mp4

I have completed the ldap authentication. Please have a look. I am now working on test and error messages.

[aashimawadhwa]

This implementation looks good to me i will review it properly till you submit the tests @skbhagat0502

[palisadoes]

@skbhagat0502

Typically the Administrator would select local authentication or LDAP as a system wide configuration. That way you wouldn’t need to have separate LDAP and regular buttons.

So there needs to be a setting at the super admin level for this. The default would be local auth, with an LDAP option. If selected, the LDAP configuration parameters would be set on that screen.

Documentation for this would need to be added to the CONFIGURATION.md file to at least know that the option exists.

Please investigate how systems using optional LDAP authentication work to see the best approach you would like to propose.

Consider a likely scenario. LDAP is enabled by the super administrator in the portal, but they don’t have an LDAP config. They are suddenly unable to administer anything. How would they recover?

[skbhagat0502]

@palisadoes, I've been delving into the documentation, and it seems that there's a need for flexibility at the community level when it comes to authentication methods. In various communities, some super admins may opt for local authentication, while others prefer LDAP. To cater to this, it makes sense to display both authentication options on the website for community members, because we cannot create different instances of Talawa admin for each community and we cannot determine which authentication method to show when users open the website.

For empowering super admins to choose the authentication method for their community, we can incorporate an option at the super admin level. We can give them access for creating a organizational unit and set up the admin credentials.
To streamline this, my suggestion is to have a single LDAP server set up centrally, managed by us. We can give access to super admins to create different organizational units (OUs) within the central LDAP server, each corresponding to a community. Super admins can manage users within their community's OU.

Storing user emails or unique identifiers within each OU will serve as a bridge between MongoDB and the LDAP server, facilitating seamless communication. This approach not only aids in preventing the locking of administrative powers for super admins but also provides a standardized and more manageable solution. Super admins can reset passwords if needed, enhancing the overall user experience.

Also we need to update the design of the login and register page. So that if a user chooses the option for ldap authentication they can choose there ou and then register and login themselves. One more thing it might be chanlenging for us to make it easy for database to communicate but I am trying to find a way. One suggestion is to have a unique identifier like email that will be used as a bridge for communication between the ldap server and the mongodb database. Also my thought is that we should manage this issue in chunks so that we can avoid any potential bugs.

I'm also gearing up to update the documentation to reflect these enhancements. Additionally, I'm on the lookout for systems that effectively implement LDAP authentication as an alternative option for more insights and best practices.

Finally my thought is that once it is merged we can work on adding the access for super admins to create ou's for there community and adding the option in the login and register page to choose a ou before login or register using ldap.
Looking forward to your thoughts and suggestions on refining these strategies.

[palisadoes]

Comments:

1. The Talawa API instance must use either LDAP or local authentication, not both. The purpose of LDAP is to have centralized access control and therefore once implemented there must not be an option for local control. This must be transparent to the user. Having a choice between login methods is not in keeping with this goal. It is not a good security practice for the end user to choose the type of security their account should have. The Admin must make the choice behind the scenes as they know best the appropriate security for their needs.
2. There needs to be a way for only the Super Admin to override the LDAP login in case they have a misconfiguration and no one can access the apps. All other users must not have a choice. You haven't explained how this would be achieved.
3. The LDAP server will be managed by the systems administrators for the community, not us.
4. Admins must not have the option of selecting the type of authentication, only Super Admins.

Questions:

1. How will you handle different user roles with LDAP?
2. Are you proposing a single OU per API instance / community?
   1. If not, how will you handle the creation of OUs for each organization in an intuitive way?
   2. If so, how will you differentiate between access to different organization?
3. Where and how will the API LDAP configuration be stored?

[skbhagat0502]

Hey @palisadoes, I got a bunch of questions swirling in my mind that I'd love to clear up all before diving into implementation. GitHub conversations tend to stretch, so was thinking, could we chat on Slack channel of talawa admin? Would really appreciate 10 mins of your time for a quick discussion. I am messaging you right now on talawa admin channel. Once you are avilable then message me. We will have a disscussion. Hope you don't mind.
Thanks.

[palisadoes]

@EshaanAgg @skbhagat0502 is having difficulties with this PR and the Husky prechecks. Can you provide some assistance?

[skbhagat0502]

Hi @EshaanAgg I am getting error when I commit. This is due to husky pre-comit. I am gettting this error in talawa api as I need to edit some unauthorized files. How could I proceed because I am not able to push my code.

[EshaanAgg]

Just add the --no-verify flag while committing and it will bypass the Husky validation. Then you can make the PR.

[skbhagat0502]

Just add the --no-verify flag while committing and it will bypass the Husky validation. Then you can make the PR.

Ok @EshaanAgg thanks.

[noman2002]

@skbhagat0502 Any update on this ?

[skbhagat0502]

@skbhagat0502 Any update on this ?

@noman2002 my college exams are going on so I am on a break. Once my exams are over I will surely get back to this.

[github-actions]

This pull request did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please verify it has no conflicts with the develop branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[palisadoes]

Are you still working on this?

[palisadoes]

Closing due to inactivity and other priorities