Bug 1404906

Summary:	Users authenticated via external sources (except LDAP) contain no default context/location
Product:	Red Hat Satellite	Reporter:	Alexey Masolov <amasolov>
Component:	Users & Roles	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED WONTFIX	QA Contact:	Katello QA List <katello-qa-list>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.2.5	CC:	amasolov, bkearney, dhawke, dhlavacd, dlobatog, itewksbu, jcallaha, kborup, mhulan, mikko.bt, mjahangi, rjerrido, tbrisker, vanhoof
Target Milestone:	Unspecified	Keywords:	FieldEngineering, Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-09-04 18:04:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexey Masolov 2016-12-15 03:47:26 UTC

Description of problem:
A similar problem as in https://bugzilla.redhat.com/show_bug.cgi?id=1104822 but for IdM/AD if they're configured directly (https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/server-administration-guide/92-using-identity-management).

Original description is still relevant:
Upon login using an 'external' user. The user cannot do anything. I've even attempted to specify an external group, but there is no context/location settings in the external group settings.

I was expecting it to be fixed but it wasn't. My current workaround is to use a foreman hook on user/after_create to modify taxable_taxonomies table.

foreman=# select id,login,auth_source_id from users where id = 38;
 id |       login        | auth_source_id 
----+--------------------+----------------
 38 | satellite-new-user |              3
(1 row)
foreman=# select id,type,name from auth_sources where id =3;
 id |        type        |   name   
----+--------------------+----------
  3 | AuthSourceExternal | External
(1 row)

foreman=# select * from taxable_taxonomies where taxable_id = 38 and taxable_type = 'User';
 id | taxonomy_id | taxable_id | taxable_type | created_at | updated_at 
----+-------------+------------+--------------+------------+------------
(0 rows)

Version-Release number of selected component (if applicable):
6.2.4
6.2.5

How reproducible:
100%

Steps to Reproduce:
1. Configure Idm as external auth source in accordance to https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/server-administration-guide/92-using-identity-managemen
2. Create new user in IDM and login to Satellite

Actual results:
As described above

Expected results:
Organzation/location are assigned on creation. 

foreman=# select id,taxonomy_id,taxable_id,taxable_type from taxable_taxonomies where taxable_id = 38 and taxable_type = 'User';
 id  | taxonomy_id | taxable_id | taxable_type 
-----+-------------+------------+--------------
 894 |           1 |         38 | User
 895 |           2 |         38 | User
(2 rows)


Additional info:

Comment 1 Marek Hulan 2016-12-15 07:33:01 UTC

Hello Alexey. How would you recommend this to be handled? When user setup external authentication like this we have no notion of where the user is stored at. We only get information that the user was authenticated externally and what are his/her user groups. We could potentially enable admin to configure orgs and locs on external auth source which is currently only available for LDAP auth sources, but that means only single set of orgs and locs would be assigned to user. This is because all users are assigned to single external auth source which represents any external service.

Would that address your use case?

Comment 2 Daniel Lobato Garcia 2016-12-15 10:07:52 UTC

I think that in the next Z-stream this feature will be available by having taxonomies on LDAP, several LDAP auth sources can be created and linked to different taxonomies (depending on the base DN for example) to address this issue. I'll look for the original issue and mark this as a duplicate.

Comment 3 Marek Hulan 2016-12-15 11:59:51 UTC

Daniel, I don't think you're right. In this case they use external auth source, not LDAP auth source. This is why I asked support for external auth source in the original PR https://github.com/theforeman/foreman/pull/3864#discussion_r79814713 but since there is no way to update external auth source by user, we didn't include it. So this is not a duplicate I think.

Comment 4 Alexey Masolov 2016-12-16 01:07:05 UTC

Hi Marek,

I believe that any external auth sources (including LDAP) should be visible in WebUI and be in one place. So, I would say the best solution is to configure taxonomies for external IdM/AD in the same way as it is implemented for LDAP. I totally understand that there are some limitations like all users are assigned to single external source. 

Would it be appropriate to rename "LDAP Authentication" to "External Authentication" in WebUI and manage all sources from there?

Comment 6 Daniel Lobato Garcia 2016-12-20 14:43:13 UTC

Yeah - sounds like 6.3.0 work based on Alexey's comment and because this is a feature. I think that's a decent enough way to do it, having just one 'external authentication' source which allows users that log in through 'external' to be mapped to at least some org/loc. 

I would suggest setting a REMOTE_USER_ORG / REMOTE_USER_LOC variable too that we could take into account upon login.

Comment 9 Kim Borup 2017-03-29 09:37:41 UTC

*** Bug 1358544 has been marked as a duplicate of this bug. ***

Comment 13 Marek Hulan 2017-08-14 19:42:24 UTC

*** Bug 1422306 has been marked as a duplicate of this bug. ***

Comment 14 Daniel Lobato Garcia 2017-10-11 08:29:21 UTC

Created redmine issue http://projects.theforeman.org/issues/21292 from this bug

Comment 18 Bryan Kearney 2018-09-04 18:04:14 UTC

Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.