Feature idea: be able to map *roles* via social/LDAP auth

[wenottingham]

ISSUE TYPE

• Feature Idea

COMPONENT NAME

• API

SUMMARY

Our social and LDAP auth can map users into orgs and teams by assorted attributes.

The request is to be able to map them into roles (team admin, execute on inventory) via attributes.

ADDITIONAL INFORMATION

1. The syntax for this must be manageable in the interface.

2. It could be argued that it might be simpler to define a team with the associated roles, and map into that.

[pjmcquade]

Hello,

I was directed here by Red Hat and it seems this topic is similar to the concerns I have around RBAC and LDAP authentication. What I describe below is based upon my current understanding of capabilities and/or limitations of Tower, so if I have misunderstood something, I'm happy to be corrected of course.

Currently I'm using tower 3.2.4 and I have the following scenario:

Let's say I have two orgs in my Tower server, East and West. They both are orgs under the same company, WeatherVane. Note: I understand the org nomenclature in Tower is to view Orgs as logically separated to such a degree where an instance of Tower could be used to host Customers that are competitors i.e. "Whole Foods" and "Walmart").

However, in my case, I want each Org to be able to create their own projects, creds, and templates. To do so, there is the admin role that can be leveraged. There is no way for a Team to do this. To summarize, I am using Orgs like Teams.

Leveraging AD and mapping in Tower, my org mappings look like this:

{
 "East": {
  "admins": "CN=EastTowerLeads,OU=User,OU=Groups,DC=weathervane,DC=com",
  "remove_admins": true,
  "users": "CN=EastTowerOperations,OU=User,OU=Groups,DC=weathervane,DC=com",
  "remove_users": true
 },
 "West": {
  "admins": "CN=WestTowerLeads,OU=User,OU=Groups,DC=weathervane,DC=com",
  "remove_admins": true,
  "users": "CN=WestTowerOperations,OU=User,OU=Groups,DC=weathervane,DC=com",
  "remove_users": true
 }
}

Given this arrangement, my East and West Leads can happily create projects, creds, templates etc, and their my East and West Operations can consume their respective Leads content.

However, what if my West Leads produce a really cool playbook they would like to share with East? Currently, this cannot be accomplished unless my West Leads are Org admins of East. But East doesn't want West to be an org admin because of the unmitigated access to projects, creds, and templates...including the power to edit/delete them. Obviously, this is not desired and would wreak havoc with Audit.

I cannot leverage Teams to do this, as I would have to create all Teams under one org to share playbooks AND Teams cannot create projects.

This ends the first enhancement request. Here's the second:

When I am an Org admin and I want to grant permission to a team, I can only see teams that are members of my Org. However, I can see users of other Orgs (provided Tower is configured to let me see all users visible to Org admins is turned on via the "SYSTEM" panel). I can see users not in my org and it appears (untested as of now) I can grant access to these users.....why not teams in another org?

So the ask:

1) I would like a user in one Tower org to be able to make available to users in another organization without also having to be an admin in the second organization. I.e. the option of one Org able to publish to another without being an admin of the other org. 2) I would like the ability to grant access to a team, and grant that access once. If someone joins or leaves that team, I don't want to have to 'refresh' the grant to ensure new members of said team get access. It looks like the "grant to team" looks like a courtesy of a "batch add to the current members of that team", but there's nothing to ensure the grants stay current as members of a team are added. I hope that makes sense.

[wenottingham]

Re: #2 - that's not the case. It's done at the team level.

[b0urn3]

Another specific use case related to this that was requested from customer:

From the Administrator guide (source: http://docs.ansible.com/ansible-tower/2.4.5/html/administration/ldap_integration.html) allowed roles (keys) for organizations are: 'admins', 'users', 'remove_admins' --> boolean, 'remove_users' --> boolean:

From the User Guide (source: http://docs.ansible.com/ansible-tower/latest/html/userguide/security.html). Reference: 21.2.2.2. Editing Organizations - ... One or more users as organization auditors ... Users who are organization auditors implicitly inherit the read-only capability for all objects within that Tower organization.

But, how to map the auditor role for organizations to the Ansible Tower LDAP configuration?

Ansible Tower configuration --> LDAP --> Organization Map

Example:

{
 "infra": {
  "users": [
   "cn=Users,ou=Personal Accounts,ou=infra,ou=organisations,ou=Development,ou=Ansible Tower,ou=Services,ou=Groups,o=ing",
   "cn=Users,ou=Non-Personal Accounts,ou=infra,ou=organisations,ou=Development,ou=Ansible Tower,ou=Services,ou=Groups,o=ing"
  ],
  "admins": [
   "cn=Administrators,ou=Personal Accounts,ou=infra,ou=organisations,ou=Development,ou=Ansible Tower,ou=Services,ou=Groups,o=ing"
  ],
  "remove_admins": true,
  "remove_users": true
 }
}

Expected:

{
 "infra": {
  "auditors": [
   "cn=Auditors,ou=Personal Accounts,ou=infra,ou=organisations,ou=Development,ou=Ansible Tower,ou=Services,ou=Groups,o=ing",
  ],
  "users": [
   "cn=Users,ou=Personal Accounts,ou=infra,ou=organisations,ou=Development,ou=Ansible Tower,ou=Services,ou=Groups,o=ing",
   "cn=Users,ou=Non-Personal Accounts,ou=infra,ou=organisations,ou=Development,ou=Ansible Tower,ou=Services,ou=Groups,o=ing"
  ],
  "admins": [
   "cn=Administrators,ou=Personal Accounts,ou=infra,ou=organisations,ou=Development,ou=Ansible Tower,ou=Services,ou=Groups,o=ing"
  ],
  "remove_admins": true,
  "remove_users": true,
  "remove_auditors": true
 }
}

[IAMShashankk]

@wenottingham any updates on this? Is it completed?

[wenottingham]

No, updates would be here if there were updates to have.

[LaurencelleJ]

Being able to map ldap groups to an auditor role for an organization as b0urn3 documented above would be extremely useful from an auditing and compliance perspective. Currently we can only do this at a user level. Having this at a group level is much easier to state who has this role during compliance reviews. I can't imagine this would be difficult to add.

[szajac01]

Also i'd like to know how it's not possible to flag by group some other role like project mananger, inventory manager. The only authorized are issuperused is_system_auditor

[wenottingham]

At a technical implementation level, superuser and system auditor are literal flags on the user; the others are roles that users are associated with.