#393 - [Proposal] - LDAP auth only for core services - Disroot/Disroot-Project - Disroot Forgejo: Brace yourself, merge conflicts ahead.

muppeth commented

2022-12-18 09:14:21 +01:00

Owner

yesterday I was thinking about the situation with ldap on disroot and came to an idea that perhpas the solution would be to keep ldap for core services only (xmpp, nextcloud, email) and for all the rest use authentication provided by the service.

Reasons for it are:

Obtaining disroot account takes time which in some cases isn't justified, and can lead to people not utilizing such tool. our gitea is a great example, where if we were to impose disroot account it would not be one of the main floss git solutions.
We already have situation where some of the services do not provide ldap on disroot, leading to cofusion. Making this clear, would make our work easier and make it clear for disrooters also.
Some of the servcies implementation is lacking (activitypub services not allowing dot in the name), or prevent other features to work correctly (cannot setup 2FA, cannot change password/email etc).
Some services do not provide ldap which would lead to split anyway as we have it already

What do you think? Should we keep LDAP (aka disroot account) for those core services only and allow people to create accounts on other servcies independently?

yesterday I was thinking about the situation with ldap on disroot and came to an idea that perhpas the solution would be to keep ldap for core services only (xmpp, nextcloud, email) and for all the rest use authentication provided by the service. Reasons for it are: - Obtaining disroot account takes time which in some cases isn't justified, and can lead to people not utilizing such tool. our gitea is a great example, where if we were to impose disroot account it would not be one of the main floss git solutions. - We already have situation where some of the services do not provide ldap on disroot, leading to cofusion. Making this clear, would make our work easier and make it clear for disrooters also. - Some of the servcies implementation is lacking (activitypub services not allowing dot in the name), or prevent other features to work correctly (cannot setup 2FA, cannot change password/email etc). - Some services do not provide ldap which would lead to split anyway as we have it already What do you think? Should we keep LDAP (aka disroot account) for those core services only and allow people to create accounts on other servcies independently?

muppeth added this to the 12.22 - December milestone 2022-12-18 09:14:21 +01:00

muppeth added the

Discussion

proposal

labels 2022-12-18 09:14:21 +01:00

muppeth self-assigned this 2022-12-18 09:14:21 +01:00

meaz was assigned by muppeth

2022-12-18 09:14:21 +01:00

fede was assigned by muppeth

2022-12-18 09:14:21 +01:00

antilopa was assigned by muppeth

2022-12-18 09:14:22 +01:00

avg_joe was assigned by muppeth

2022-12-18 09:14:22 +01:00

muppeth added this to the 12.22 - December project 2022-12-18 09:14:23 +01:00

muppeth changed title from ~~Propsal - LDAP auth only for core services~~ to [Proposal] - LDAP auth only for core services

2022-12-18 09:50:40 +01:00

avg_joe commented

2022-12-18 13:51:56 +01:00

Owner

tricky one!
i love it the way it is and would be great to have more (like cryptpad)
of course there are reasonable expections like git,
but in general i like it the way it is
and dislike the idea to have like 10 accounts to use all services.

tricky one! i love it the way it is and would be great to have more (like cryptpad) of course there are reasonable expections like git, but in general i like it the way it is and dislike the idea to have like 10 accounts to use all services.

meaz commented

2022-12-18 14:26:22 +01:00

Owner

I also like the fact to have one account to rule them all. And I think that is what people are expecting...

Obtaining disroot account takes time which in some cases isn't justified, and can lead to people not utilizing such tool. our gitea is a great example, where if we were to impose disroot account it would not be one of the main floss git solutions.

We already have situation where some of the services do not provide ldap on disroot, leading to cofusion. Making this clear, would make our work easier and make it clear for disrooters also.

We had this idea a while back to automate account creation, except for email one that would get a review as we already do. We could then have ldap on all services to avoid this confusion.

Some of the servcies implementation is lacking (activitypub services not allowing dot in the name), or prevent other features to work correctly (cannot setup 2FA, cannot change password/email etc).

That is a good point.
Could we have 2FA at a higher level? For example a login page that would allow to directly logged in all services at once... Then, we could provide 2FA on that page.
Though I'm wondering if people could still log in on service page directly, which would then be pointless...

Some services do not provide ldap which would lead to split anyway as we have it already

That is another good point.

I also like the fact to have one account to rule them all. And I think that is what people are expecting... > Obtaining disroot account takes time which in some cases isn't justified, and can lead to people not utilizing such tool. our gitea is a great example, where if we were to impose disroot account it would not be one of the main floss git solutions. > We already have situation where some of the services do not provide ldap on disroot, leading to cofusion. Making this clear, would make our work easier and make it clear for disrooters also. We had this idea a while back to automate account creation, except for email one that would get a review as we already do. We could then have ldap on all services to avoid this confusion. > Some of the servcies implementation is lacking (activitypub services not allowing dot in the name), or prevent other features to work correctly (cannot setup 2FA, cannot change password/email etc). That is a good point. Could we have 2FA at a higher level? For example a login page that would allow to directly logged in all services at once... Then, we could provide 2FA on that page. Though I'm wondering if people could still log in on service page directly, which would then be pointless... > Some services do not provide ldap which would lead to split anyway as we have it already That is another good point.

muppeth commented

2022-12-18 22:34:10 +01:00

Author

Owner

Thanks for your feedback.

I do also like the idea of having one credentials for everything. But from my experience in years of running disroot, it's not as easy and bump free and sometimes impossible. Longer this lasts the more issues we have. As an example, taiga implementation is broken to the point we had to fork their frontend to prevent user/password update in it. However due to other priorities and issues with build script etc. it remains broken for year now. We have decided to drop taiga, but the this shows we will have issues in the future and we simply might not have capacity or skill to keep things forked and modified in-house.

This is why I decided to find a solution to this that is future proof. To avoid having to explain why some services need disroot account and some not ("because we want to reach more people easily for collaboration in case of git" or "because of end to end encryption in case of cryptpad" or "because of ldap not suported in case of lemmy or pixelfed or " or "you need to use _ instead of . when logging in because of reasons in case of akkoma"), I thought of making a standard and devision between core services and everything else. Simply to unload on some of the work, and make it more clear for users.

Thanks for your feedback. I do also like the idea of having one credentials for everything. But from my experience in years of running disroot, it's not as easy and bump free and sometimes impossible. Longer this lasts the more issues we have. As an example, taiga implementation is broken to the point we had to fork their frontend to prevent user/password update in it. However due to other priorities and issues with build script etc. it remains broken for year now. We have decided to drop taiga, but the this shows we will have issues in the future and we simply might not have capacity or skill to keep things forked and modified in-house. This is why I decided to find a solution to this that is future proof. To avoid having to explain why some services need disroot account and some not ("because we want to reach more people easily for collaboration in case of git" or "because of end to end encryption in case of cryptpad" or "because of ldap not suported in case of lemmy or pixelfed or " or "you need to use _ instead of . when logging in because of reasons in case of akkoma"), I thought of making a standard and devision between core services and everything else. Simply to unload on some of the work, and make it more clear for users.

muppeth commented

2022-12-18 22:38:43 +01:00

Author

Owner

@fede @antilopa can you check this and give your feedback?

muppeth commented

2022-12-18 22:39:11 +01:00

Author

Owner

Oh. btw. there is no ldap support for lemmy as of yet (pending issue for over a year)

muppeth commented

2022-12-24 09:56:29 +01:00

Author

Owner

I gave this issue quite some thought last days, and my opinion has changed 180 degrees :)
The problem with moving away from ldap does cause number of other issues which can make things even worse. Disroot account is sort of a disroot ID. We dont want to endup in a situation where muppeth on xmpp is a different muppeth on akkoma etc.

So I do agree with you guys and think we need to rather find solutions to keep disroot id concept working on as many services as possible.

I gave this issue quite some thought last days, and my opinion has changed 180 degrees :) The problem with moving away from ldap does cause number of other issues which can make things even worse. Disroot account is sort of a disroot ID. We dont want to endup in a situation where muppeth on xmpp is a different muppeth on akkoma etc. So I do agree with you guys and think we need to rather find solutions to keep disroot id concept working on as many services as possible.

👍 2

fede commented

2022-12-26 04:32:48 +01:00

Owner

I also think we should keep things simple, so one Disroot account should cover all the services that support LDAP. That some other services, those more focused on social or collaboration interactions (Gitea, Lemmy), require to create a separate account makes sense to me because of what @muppeth commented "Obtaining disroot account takes time which in some cases isn't justified, and can lead to people not utilizing such tool"

I also think we should keep things simple, so one Disroot account should cover all the services that support LDAP. That some other services, those more focused on social or collaboration interactions (Gitea, Lemmy), require to create a separate account makes sense to me because of what @muppeth commented "*Obtaining disroot account takes time which in some cases isn't justified, and can lead to people not utilizing such tool*"

antilopa commented

2022-12-26 09:49:20 +01:00

Owner

I think finding better solution to keep disroot id across all services, so that the process of getting a disroot account is simple and quick is better the continuing splitting services that do or don't use Disroot id. It is already confusing as it is and having the same id on e.g Xmpp, Akkoma and whatever forum solution we go for can be quite important imo.

👍 2

muppeth closed this issue

2023-01-04 21:06:38 +01:00

[Proposal] - LDAP auth only for core services #393