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

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

Open
benyanke opened this issue Jul 3, 2018 · 8 comments
Open

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

benyanke opened this issue Jul 3, 2018 · 8 comments
Labels
enhancement New feature or request help wanted Extra attention is needed pinned

Comments

@benyanke
Copy link
Contributor

benyanke commented Jul 3, 2018

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
Copy link
Member

madmath03 commented Jul 6, 2018

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
Copy link
Contributor Author

benyanke commented Jul 7, 2018

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
Copy link
Contributor Author

benyanke commented Jul 7, 2018

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
Copy link

irrgit commented Jan 31, 2019

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
Copy link
Member

@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
Copy link

stale bot commented Jun 17, 2019

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.

@stale stale bot added the wontfix This will not be worked on label Jun 17, 2019
@madmath03 madmath03 added pinned and removed wontfix This will not be worked on labels Jun 17, 2019
@madmath03 madmath03 pinned this issue Jun 17, 2019
@MichaelHierweck
Copy link

MichaelHierweck commented Aug 18, 2019

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed pinned
Projects
None yet
Development

No branches or pull requests

5 participants