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

LDAP Support #118

Closed
hhenkel opened this Issue May 31, 2016 · 19 comments

Comments

Projects
None yet
@hhenkel

hhenkel commented May 31, 2016

From what I've seen so far users are stored in the database. It would be nice to have LDAP support, so that one could use existing groups to match "roles" and people could use their central managed password.

@Echobob Echobob added the enhancement label May 31, 2016

@rguiliani

This comment has been minimized.

rguiliani commented May 31, 2016

+1

@gasperzupancic

This comment has been minimized.

gasperzupancic commented Jun 3, 2016

that would be awesome!

edit: sorry didnt know github +1 existed:)

@matejkramny

This comment has been minimized.

Member

matejkramny commented Jun 8, 2016

Please use github's reactions for +1's. Thanks!

This will be done when everything else is out of the way. There are currently more pressing things like an unfinished UI and dynamic inventories!

@Gianlu

This comment has been minimized.

Gianlu commented Jun 13, 2016

+1

@matejkramny

This comment has been minimized.

Member

matejkramny commented Jun 16, 2016

Ok guys, in order to build this i need to know some detail.

Can you provide a use case?
is google apps (for business) an LDAP provider that you would use?
How would google apps permissions apply inside semaphore?

@hhenkel

This comment has been minimized.

hhenkel commented Jun 16, 2016

Okay, I'll give it a try - hope it gets not to complicated and understood what you've been asking for.

My usecase would look like this:

In LDAP users are part of one or more ldap groups. IMHO it would be a good idea to have the concept of roles, so that users or groups can be mapped to a role (mapping of groups is prefered).

Ideally semaphore would provide multi-tenancy capability. Therefore I got multiple groups of users that should be able to have one or more projects. They should not be able to see other projects, but should be able to create new projects. Therefore I might be a good idea to introduce something like "organization". Within a project I would need at least two different types of roles, project administator and executer role.
For the ldap part I would need the ability to map one or more ldap groups to the administrator role of the project. For the executer role it would be nice to have the ability to have multiple entities, so that one could map different ldap groups to different executer entitities. Then it would be possible for the administrator to allow a specific executer entity to run specific ansible jobs.

For beeing able to use this in a sane way I would suggest the following

  • Add "organization" layer for multi-tenancy
  • Enhance the role concept in semaphore:
    • Application Administrator Role
    • Project Administrator Role
    • Executer Role
  • Make it possible to assign one or more executer groups to commands.

Nice to have:

  • Make commands groupable

This is a proposal - I'm open for discussion.

@Gianlu

This comment has been minimized.

Gianlu commented Jun 16, 2016

Hi,
I agree with @hhenkel. My use case is to authenticate users via active directory and it is (more or less) an ldap server. I need to authenticate users and map roles to users' groups for authorization.
@hhenkel proposed a good auhorization pattern.

@KarenTovmasian

This comment has been minimized.

KarenTovmasian commented Nov 10, 2016

any plans for implementation of this? we need to auth users from AD or from Google (both works for us)

@gcavalcante8808

This comment has been minimized.

Contributor

gcavalcante8808 commented Nov 15, 2016

@hhenkel @matejkramny Based on what hhenekl said, Initially I thought something like this for the Backend:

auth

With in this in mind, we can think about the following behavior:

  • The Entity table have the information about data connection options and name;
  • An default 'Internal' entity will be included by default(fixtures);
  • An User have an Entity (only one) which can can be 'Internal', an 'LDAP User', or something else (maybe HTTP auth in the future?);
  • The Permission table have permission names: maybe something bound to our api calls, like "task_template_run", "task_template_update", "task_template_create" would be nice;
  • The roles_permissions tables maps an Role to a number of permissions;
  • The Role table have the role name;
  • The project_user_roles is a m2m that maps user->role-> project, so our user can have different roles in different projects;

To start, if have thinking about roles maybe we should implement an RBAC model ... but we are using angular to provide our frontend ... In this point I really don't have a clue (maybe a check within a service?) about how path we should go ... In the github we have https://github.com/mikespook/gorbac project for the server side ...

To finish the job we need an Authorization Management interface to manage Entities, Roles, Permissions.

What you think?

@gcavalcante8808

This comment has been minimized.

Contributor

gcavalcante8808 commented Dec 7, 2016

I think that we should start with simplest approach: implement LDAP authentication with the authnz_entity table and integrate it with the GIN framework.

The following lib looks like to be the best implementation for now:

https://github.com/mavricknz/ldap

@mcassaniti

This comment has been minimized.

mcassaniti commented Feb 23, 2017

I'm seeing two issues rolled together here. I too am in an AD environment, and I'm after a multi-tenant solution. You need three parts to solve the multi-tenant side:

  1. User to authentication type mapping (the entity and entity_type tables)
  2. RBAC
  3. Groups or Organizations

I would suggest splitting RBAC into a separate issue since its implementation is independent of AD authentication. The other part that is missing from your RBAC model is limiting not only what actions can be performed, but what objects or group of objects they can be performed on. This is where the concept of an organization, or a mapping to a group is important.

To elaborate, if I can assign either an organization or a group to an inventory, then that group or organization can be used to limit which users can access that inventory. This is orthogonal to what a user can do with that inventory. Organizations are a 1:1 mapping to the object (in this case an inventory item), whereas groups are generally many to many.

@strangeman

This comment has been minimized.

Collaborator

strangeman commented Mar 24, 2017

Hi, guys. I plan to implement a simple LDAP auth here, like "If this LDAP user have right password and belongs to right LDAP subtree - add it to the users table and authorize him". After, if it will be work good - we can do more complex things, like inventory/project/etc limitations.

@strangeman

This comment has been minimized.

Collaborator

strangeman commented Mar 27, 2017

Added simple LDAP auth as described in my previous comment.

@Echobob

This comment has been minimized.

Member

Echobob commented Apr 17, 2017

Closed by #310

@Echobob Echobob closed this Apr 17, 2017

@matejkramny

This comment has been minimized.

Member

matejkramny commented May 20, 2017

Now that LDAP is integrated (& soon the security issue fixed), I have some questions for you guys since I don't use LDAP systems.

Should the users be created in semaphore if they don't exist in the semaphore database but have been authenticated using LDAP?

Soon we'll have a better permissions system (starting with @strangeman's PR). Does LDAP have a permission system that semaphore can utilise?

We could also poll for users from the LDAP system and do something with that.

@pasikarkkainen

This comment has been minimized.

pasikarkkainen commented May 20, 2017

@matejkramny : Can you please link the permissions PR you mentioned?

Usually one uses LDAP groups, and map them to roles.. is that what you need, or something else?

@matejkramny

This comment has been minimized.

Member

matejkramny commented May 20, 2017

@hhenkel

This comment has been minimized.

hhenkel commented May 22, 2017

@matejkramny I'll try to describe quickly what I've seen in other applications:

Other application normaly allow you to specify an ldap search string, which can consist of multiple "conditions" or "rules" (and / or combinations).

For the mapping part it is a s I initialy wrote and comes down to what @pasikarkkainen wrote:

A user is normally a member of 1 to n groups
A group normally consists of 1 to n members

An application normally works with the concept of roles like "admin" or "user". When using an LDAP backend you normally try to map groups to roles to make administration easier but one could also map specific users to a role.

Possibly. My understanding of this: If one user was in the "admins" LDAP group and it was configured to map to the "admin" permission in semaphore, upon logging in for the first time (effectively signing up to semaphore) the user would be automatically "admin".

You should always evaluated if the user still is in the admin LDAP group and not depend on what has been set in the database, as the permissions could have been revoked in the LDAP.

@strangeman

This comment has been minimized.

Collaborator

strangeman commented May 22, 2017

Currently, Semaphore haven't 'admin' users (see #318)

Also, we should be able to map LDAP groups to the different Semaphore projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment