Monogramm / taiga-contrib-ldap-auth-ext

:snake: :alembic: Extended Taiga plugin for LDAP authentication
http://taiga.io
GNU Affero General Public License v3.0
45 stars 15 forks source link

Auto Add to Group on Login By LDAP Query [Future Wishlist] #15

Open benyanke opened 6 years ago

benyanke commented 6 years ago

In my org, we have a lot of team members who we'd like to automatically be part of a group, not needing to be invited. Additionally, as people come and go, we'd like to federate auth/authorization to AD, but also group membership.

Starting this ticket to track progress on a feature which would enable membership in a project based on an ldap query for each role.

When I have time, I'll start to implement, if you're interested, otherwise I'll just keep it in a fork (though I'd hate to make another fork!)

madmath03 commented 6 years ago

Adding LDAP group management into Taiga would definitely be the next level of integration that this plugin needs.

I'm interested in this and we actually thought about it in my company but never settled on how groups should be used inside Taiga and decided to leave it as is since the current behavior was enough for us.

There are several aspects that should be well thought regarding group management before implementation.

I do not have much time to help you implementing this, but I will give all the support I can discussing the design and functionalities 😉

Project / Role mapping

For instance, if we assume that you have one LDAP group by project, how are you going to associate them ? The best would be to set the LDAP groups specifically by project but that would require a user interface development... which would be far too much for this plugin. So a setting in settings/local.py ? But if you need to edit Taiga config file each time you have a new project or a new role, that might become really bothering to manage.

Maybe the easiest would be to setup a LDAP group pattern. For instance:

# Group search filter where $1 is the project slug and $2 is the role slug
LDAP_GROUP_SEARCH_FILTER = 'CN=$2,OU=$1,OU=Groups,DC=example,DC=net'

Such a structure would allow a system admin to only do one configuration and then create the LDAP groups matching the Taiga project's slugs, so really easy to manage. The only problem I see with this system is what to do if a user has several LDAP "roles" for a same project ?

Group membership

For as much compatibility with different LDAP systems as possible (OpenLdap, AD, ...), we should be able to define how to retrieve membership : either by attribute or group.

# USER ATTRIBUTE
# Use an attribute in the user entry for membership
LDAP_USER_MEMBER_ATTRIBUTE = 'memberof,primaryGroupID'

# LDAP GROUP
# Starting point within LDAP structure to search for login group
LDAP_GROUP_SEARCH_BASE = 'OU=Groups,DC=example,DC=net'
# Group classes filter
LDAP_GROUP_FILTER = '(|(objectclass=group)(objectclass=groupofnames)(objectclass=groupofuniquenames))'
# Group member attribute
LDAP_GROUP_MEMBER_ATTRIBUTE = 'memberof,primaryGroupID'

Problem is : how do we define the role of the user with a user attribute ? Should we consider the value of this attribute to have a special format? Like project1-slug&role-slug ; project2-slug&role-slug ? If so, we should define a parameter for that as well but it feels a bit ugly...

Super user

It is possible through the Django administration to setup a user as a "super user", giving him all permissions.

Wouldn't it make sense to be able to define a global Taiga administration group ?

# Taiga super users group id
LDAP_GROUP_ADMIN = 'OU=TaigaAdmin,DC=example,DC=net'
benyanke commented 6 years ago

Lots of good ideas there. I'm wondering if there could even be a more flexible method: allow a configurable string for each group containing an ldap query? That way, taiga could be configured as flexibly as possible, possibly requiring no domain changes.

This could, however, be combined with your methods above, using variables in the ldap query. One variable could be the slug of the group, for example, another the ID, etc.

Thoughts?

benyanke commented 6 years ago

Additionally, in conjunction with this issue - one other major pain point we have is the invite system. Really, i'd like for an LDAP user to exist in taiga, with proper permissions. As it is now, LDAP acts to verify U/PW, but beyond that, they still have to be invited to a group, to accept the invite, etc.

This issue is really the only thing stopping us from taking our taiga rollout serving about 10 users in the company to a rollout available to the entire company.

I wonder if this membership code work could also handle some of this as well.

irrgit commented 5 years ago

This would be a nice feature. Is there currently a way to automatically add users by simply knowing their email? And by that I mean either going to taiga /admin/ and adding them there and somehow having them be ldap users, or scripting some temporary solution to add users manually en masse. Because Adding users click by click would be tedious.

madmath03 commented 5 years ago

@irrgit I'm not really sure to understand your use case here. I mean, I understand how it would be nice to be able to import massively users into Taiga if you're not using LDAP (in that case, this would rather be a question for Taiga core team) but both do not make sense to me since a user present in the LDAP would automatically be created in Taiga on first login so there isn't a need to import them anymore as long as they are in the LDAP and login once. Am I missing something ?

Anyway, I can at least tell you I do not know any existing function in Taiga that would allow mass creation of users but I guess it could be easy to do by making a small script reading user/passwords from a file and calling the API with some admin credentials.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

MichaelHierweck commented 5 years ago

We already can fetch users from LDAP. Thanks. If we could also fetch groups and determine group memberships we would furthermore like to be able to map group memberships to project specific roles.

Maybe this simple kind of mapping via configuation file would be sufficient.

[
  'dc=com,dc=example,ou=groups,cn=projectteam' : 
      [{'myproject' : 'developer'}, {'otherproject ': ['viewer', 'wikieditor']}],
  'dc=com,dc=example,ou=groups,cn=boss' : 
     [{'*' : 'manager'}]
]

Meaning:

Members of the "projectteam" group are granted the "developer" role on project "myproject" and the "viewer" and "wikieditor" roles on project "otherproject". Members of the "boss" group are granted the "manager" role on any project.

Note:

This should be fault tolerant. If a project or a project specific role does not exist, the plugin should skip the assignment and proceed. Maybe the pattern matching could be implemented with regular expressions.

evandroteixeira1710 commented 3 years ago

Good afternoon, At the company I work for, we currently use atlassian tools, but as the demand for employees has grown, they don't want to have a high cost of licenses. I found Taiga and at first I found it to be a simple tool that suits the kanban and scrum project we use. However I have some doubts regarding LDAP... In Atlassian tools, we work as follows: Atlassian General Group - Subgroups with project names - Each subgroup has the name of project-admin, project-dev, project-user - If there is a member only in project A, he cannot see the other projects or access them. Can I configure it that way?

NOTE: I've already managed to validate the company's AD, I'm wanting to do this configuration with groups.