Open jamesmarshall24 opened 5 years ago
We do not map RBAC roles, only organizations and groups, and we restrict those to things that are more traditional enterprise directories. TACACS authorization doesn't really map to Tower objects.
Hi Bill and Team,
The above Feature request was raised by James on my behalf (Case #02396390) after our discussion. We would like to use either RADIUS or TACACS+ for remote user authentication and authorization. The authentication part exists today but the authorization part will be used to return back to Ansible Tower the User type value (normal user, system auditor, system administrator, etc.) and also the user permissions using RADIUS or TACACS+ vendor-specific attributes. That way, rather than having to define all users locally in Ansible Tower, in order to be able to give them different permissions we’ll be able to define RADIUS/TACACS authentication plus authorization; this provides several benefits:
Let me know what you think.
See above; we don't map roles via directory platfoms, only organizations and groups.
Ok. What does 'Group' mean here? I could not find anything called 'group' in the tower. Also, if you can explain how the organizations and group mapping is done or share a link to read more on this information?
So we would have to first add all the users and assign them roles in the tower as you suggested there is no way to set access permissions using RADIUS or TACACS with Tower.
We were thinking of having an option for allowing to map the users with permission (or a sort of "permission group") would allow avoiding having to define local accounts on the system and will provide more scalability and easier user management.
Please tell what's the best approach to do it?
Hello @b2sweety,
The way this works with other auth providers is you preemptively map out the permissions at the team level. The RBAC roles which provide certain permissions to objects in Tower (objects such as Teams in this instance) are covered in our Security: Role Based Access Controls documentation.
The auth provider returns the user information. In the case of LDAP/SAML, you can map other attributes in the returned details to specific organizations and teams. These teams have the inherent permissions to access particular objects based on your RBAC mapping described in the above paragraph.
I think this may be quite limiting to adoption for some enterprises. Within our support group, RADIUS and TACACS+ is the common AAA platform for network infrastructure and is well known/understood/supported. From a security perspective, it places the authorization responsibility with the AAA platform, which in our case is the security team, and removes authorization from the application owner (e.g., Ansible Tower). Active Directory only provides group/org membership, and the authorization responsibility lies with the application owner (I.e., the fox is watching the hen house). If Ansible is only for servers and clouds, the status quo is fine. If we want it leveraged by corporate networks, we need full RADIUS support (and TACACS+ would be a perk).
This has become quite an issue with our design and deployment for Tower. We use TACACS Attribute mapping to manage authorization for most of our systems. I submitted an RFE with Redhat and they directed me here. Are there any thoughts to include this as a feature?
ISSUE TYPE
SUMMARY
Add organization, team, and RBAC mapping to RADIUS/TACACS auth provider.