Change LDAP directory structure to accommodate multiple domains #127
Labels
No Label
service
accounts
service
discourse
service
drone-ci
service
email
service
garage
service
gitea
service
ipfs
service
mastodon
service
postgres
service
remotestorage
service
wiki
service
xmpp
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
release
major
release
minor
release
patch
security
ui/ux
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Blocks
#123 Enable LDAP support on ejabberd
kosmos/chef
Reference: kosmos/chef#127
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
raucao referenced this issue2020-01-30 16:18:10 +00:00
Proposed hierarchy:
For comparison here is our current hierarchy that does not support domains:
Here's what the ldif files for the proposal would look like:
And this is what a user would look like:
Does that look correct to you?
Looks good. But shouldn't
wikiandxmpprather be user groups?This is also missing the groups considerations (or whatever other solution may make sense) for Gitea orgs for example.
Please think outside the box there, because it's complete greenfield and we haven't decided on any pricing/donation structures. For example either a minimum donation amount in general (no matter for which service) could allow a user to create one or more orgs. Or, akkounts-api could create orgs without users being allowed to create their own.
Also, one small thing: Gitea (and likely other services too) allows uppercase letters in usernames.
One more thing:
"mail" should probably be split into "smtp" and "imap". And we need an actual "email" property for the user's own (fallback) email.
Edit: Gitea suggest "mail" as well, so this is just an idea.
Gitea also supports an attribute for SSH public keys, and a bunch of other things:
https://gitea.kosmos.org/admin/auths/new
In fact, LDAP support in Gitea looks pretty darn good!
mailis part of the standard attributes on a User/Account for email. Gitea supports does look very good and flexible! Gitea allows to set the mail attribute you want, but most LDAP integration doesn't give you that flexibility. Most of the time you can only set the User Base and a User FilterI'm looking into groups and roles to find out ways that would work with organizations, as well as services
So far I think for the use case of enabling different services, that roles, in particular filtered roles would be a good fit.
Right now I cannot think of a good use of groups for us. This would be useful for giving out people UNIX accounts and adding them automatically to a UNIX group, for example.
memberOfgives you a similar experience to filtered roles, except it only works on static groups, not on dynamic groups created withgroupOfURLs(that can be used similarly to filtered roles). So at first glance I thought dynamic groups would be great, until I figured out then it's not convenient to know what dynamic group a user belongs to.Filtered roles
Here is an example of a filtered role:
In this example I am using a simple filter, but it can be more complex. When filtering from just one attribute it is as easy to filter directly using the attributes.
Then you can filter users that have the role applied:
Static group
Here is an example of a static group:
Static groups need a plugin to be abled, that consists of enabling it and setting the attributes on the group and the account:
The 389 server then needs to be restarted, and it's easier to only create the users after this, otherwise the
memberOfvalues need to be regenerated. I haven't found a way to successfully regenerate these on the version of 389 that ships with Ubuntu 18.06Then you can list users in the group, and see if a user is a member of a group:
Do you have questions about filtered groups? Do you think it is a good fit for us>? Of course using attributes means they need to be locked down, so users cannot edit any attribute on their own account except for their email and password. This should be done as part of #128
Gitea & organizations
When it comes to Gitea, the LDAP support is for authentication, including adding admin privileges to users, but it looks like we'll have to deal with organizations ourselves. On an LDAP user/account there is a
oattribute, for exampleo=kosmos. I think adding users to organizations could be done as a Gitea plugin or using the APIIt seems like there's misunderstanding about what we need from akkounts in regards to orgs. The important thing is not adding users to organizations, but to allow users to create organizations. As you say, this most likely needs to be done via the Gitea API from
akkounts-api, but the LDAP directory needs to have a flag for this somewhere.OK, now I understand. In Gitea there is a global setting for "Allow Creation of Organizations by Default", that is off by default and off in our deployment. Admins can always create organizations, and there's also a flag on regular users for their ability to create organizations if needed
For Pro users we could create the Gitea organization, then add the users to the Gitea org. In LDAP the users being under the
ou=customer.pro,cn=users,dc=kosmos,dc=orgsuffix would be enough. So I think all we need is to add adescriptionto store the org's name, because so far we only had the domain. So a Pro org in LDAP would look like this (added thedescriptionattribute):I also found this project in a Gitea issue: https://github.com/tws-inc/gitea-group-sync
It's very difficult to discuss these topics when the terms used are either inaccurate, or they exist but for something different.
Thanks for clarifying it, this is all clearer to me now
By the way, filtered roles seem like a good solution for enabling/disabling services. 👍
One of the main questions I still have is if we somehow keep donation status in LDAP, or if we need yet another database/storage for that.
I agree, here's a filtered role example (for the 5apps XMPP config): #123 (comment)
Now that I have figured out the LDAP ACIs, I think donation status can be stored in LDAP. The filtered role could use an extra donation status field to determine if an account is enabled or not
It's not so much about if the account is enabled, but when to send a message to donate again.
Moved from the ejabberd issue:
I ran into an issue with MediaWiki in my VM when using the new LDAP schema. I was preparing the config for MediaWiki, and I cannot make the LDAP authorization work using the filtered role. It looks like we have to use an attribute directly to perform the auth check in the MediaWiki config. I will take another look at this tomorrow
Why do we have to filter anything? We agreed that every user should have a wiki account, no matter what (and that we may want to do the same with other accounts, like e.g. personal Gitea accounts).
Yes, in the end removing the LDAPAuthorization Mediawiki extension works in this case, no need for filtering. I'm pushing a PR with the config changes
Closing this one since we've migrated ejabberd
Docs are on the wiki page: https://wiki.kosmos.org/Infrastructure:LDAP