Adding users from different domain to a group

[Bajarang Jadhav]

I have created two domains. And I have created users in both the domains. I created a group in first domain, and I tried adding those users from other domains to this group, it added successfully.

But according to this page https://wiki.openstack.org/wiki/Domains, it should not allow.

Here are the steps to reproduce this :-
created new domain Domain9

curl -i -k -X POST https://url/v3/domains -H "Content-Type: application/json" -H "X-Auth-Token: $token" -d @domain.json
HTTP/1.1 201 Created
Date: Fri, 10 Jul 2015 09:48:15 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 214
Content-Type: application/json

{"domain": {"links": {"self": "https://url/v3/domains/dc1d36c037ac4e47b3b21424f1a13273"}, "enabled": true, "description": "Description.", "name": "Domain9", "id": "dc1d36c037ac4e47b3b21424f1a13273"}}

created user fd22 in domain Domain9

 curl -i -k -X POST https://url/v3/users -H "Content-Type: application/json" -H "X-Auth-Token: $token" -d @user.json
HTTP/1.1 201 Created
Date: Fri, 10 Jul 2015 09:49:27 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 269
Content-Type: application/json

{"user": {"links": {"self": "https://url/v3/users/533979e9b80645799028c51ccec55cce"}, "description": "Sample keystone test user", "name": "fd22", "enabled": true, "id": "533979e9b80645799028c51ccec55cce", "domain_id": "dc1d36c037ac4e47b3b21424f1a13273"}}

created user fd23 in default domain

vi user.json
provo-sand:~/bajarang # curl -i -k -X POST https://url/v3/users -H "Content-Type: application/json" -H "X-Auth-Token: $token" -d @user.json
HTTP/1.1 201 Created
Date: Fri, 10 Jul 2015 09:50:56 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 244
Content-Type: application/json

{"user": {"links": {"self": "https://url/v3/users/8a43e5f3facb4fc2985a18a40de2046e"}, "description": "Sample keystone test user", "name": "fd23", "enabled": true, "id": "8a43e5f3facb4fc2985a18a40de2046e", "domain_id": "default"}}

created group DomainGroup10 in default domain

curl -i -k -X POST https://url/v3/groups -H "Content-Type: application/json" -H "X-Auth-Token: $token" -d @newgroup.json
HTTP/1.1 201 Created
Date: Fri, 10 Jul 2015 09:52:49 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 225
Content-Type: application/json

{"group": {"domain_id": "default", "description": "Description.", "id": "0b72f1dd6f514adb989a752b9a72e005", "links": {"self": "url/v3/groups/0b72f1dd6f514adb989a752b9a72e005"}, "name": "DomainGroup10"}}

Added user 'fd22' from Domain9 to DomainGroup10

curl -i -k -X PUT https://url/v3/groups/0b72f1dd6f514adb989a752b9a72e005/users/533979e9b80645799028c51ccec55cce -H "Content-Type: application/json" -H "X-Auth-Token: $token"
HTTP/1.1 204 No Content
Date: Fri, 10 Jul 2015 09:53:17 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 0

Added user 'fd23' from Default to DomainGroup10

 curl -i -k -X PUT https:/url/v3/groups/0b72f1dd6f514adb989a752b9a72e005/users/8a43e5f3facb4fc2985a18a40de2046e -H "Content-Type: application/json" -H "X-Auth-Token: $token"
HTTP/1.1 204 No Content
Date: Fri, 10 Jul 2015 09:54:20 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Vary: X-Auth-Token
Content-Length: 0

[Steve Martinelli (stevemar)]

Can you do a listing on the domains to see if fd22 and fd23 have indeed moved? Our PUT operations will always return 204

Also, some things are a bit weird

"Added user 'fd22' from Domain9 to DomainGroup10" << does this mean Domain9 was a 'group' or a 'domain'?

I'm not seeing a problem in the last operations "Added user 'fd23' from Default to DomainGroup10"

  - fd23 is a user in the default domain
  - DomainGroup10 is a group in the default domain
  - you added a user to a group. this is fine.

Domains are a store for {groups, users, projects}. Groups are a store for {users}.

[Bajarang Jadhav (bajarangmca)]

Hi Steve,

when I did the listing of users in DomainGroup10, got the following output

curl -i -k -X GET -H "Content-Type: application/json" http://identity/v3/groups/0b72f1dd6f514adb989a752b9a72e005/users -H "X-AUTH-TOKEN:$token"

{"users": [{"links": {"self": "https://identity/v3/users/533979e9b80645799028c51ccec55cce"}, "description": "Sample keystone test user", "name": "fd22", "enabled": true, "id": "533979e9b80645799028c51ccec55cce", "domain_id": "dc1d36c037ac4e47b3b21424f1a13273"}, {"links": {"self": "http://identity/v3/users/8a43e5f3facb4fc2985a18a40de2046e"}, "description": "Sample keystone test user", "name": "fd23", "enabled": true, "id": "8a43e5f3facb4fc2985a18a40de2046e", "domain_id": "default"}], "links": {"self": "https://identity/v3/groups/0b72f1dd6f514adb989a752b9a72e005/users", "previous": null, "next": null}}

 'Domain9' is a domain. 'DomainGroup10' is group in the 'default' domain.

[jiaxi (tjxiter)]

@Steve Martinelli (stevemar):
Domains are a store for {groups, users, projects}. Groups are a store for {users}.

DomainA = { group1, group2,user1,user2, project1}, group1 of DomainA = [user1, user2]

DomainB = { group1, group2,user1,project1} , group2 of DomainB = [user1, user2]

Now you add user1 of DomainB'group2 to DomainA's group1. Now DomainA has two user1,This is wrong.
Because users in a group should be global unique.

[Henry Nash (henry-nash)]

I disagree. This was an explicit part of the design to allow users from one domain to be part of the group of another domain. Group membership is based on UserID (not name) so the users are distinguished.

[Henry Nash (henry-nash)]

(The web page referenced in this big report is wrong, and predates (I assume) any implementation of domains - so if there is a bug, it's that this page should be amended.

[Steve Martinelli (stevemar)]

as Henry said, this isn't a bug.

[Dolph Mathews (dolph)]

I agree with Henry in comment #4 and #5.

[OpenStack Infra (hudson-openstack)]

Change abandoned by jiaxi (<email address hidden>) on branch: master
Review: https://review.openstack.org/202438
Reason: Invalid bug.

[Bajarang Jadhav (bajarangmca)]

@ Steve Martinelli (stevemar), @Henry Nash (henry-nash),@jiaxi

In UI, I found that, users from one domain are not allowed to be part of the group of another domain..

Steps followed:
1. Created 2 domains, domain1 and domain2
2. Created users, user1 in domain1 and user2 in domain2.
3. Created groups, group1 in domain1 and group2 in domain2.
4. In UI, tried to add user1 to group2. While "Add users" is clicked in "Group Management" page of group2, it shows only user2.Have attached the screenshot of the same.
5. Same behavior is observed while adding user2 to group1.

As per the discussion above, users from one domain are allowed to be part of the group of another domain.In CLI, same behavior is observed, however in UI, the behavior is different as mentioned in the above steps.

Can you please let me know if UI is behaving as designed?

[Henry Nash (henry-nash)]

Could I ask if you are using domain specific backends (e.g. default in SQL and another domain in LDAP, or two different LDAPs)? What we don't allow is group membership across such backend technology boundaries.

[Bajarang Jadhav (bajarangmca)]

@Henry Nash (henry-nash),

We are not using any external LDAP..

[Henry Nash (henry-nash)]

Ok, thanks (and if it works with the CLI, then that shows us that the server is doing what is expected). This looks like a restriction in Horizon - that they are only displaying users with the same domain as the group - I suspect the problem is here:

    def _get_group_non_members(self):
        domain_id = self._get_group().domain_id
        all_users = api.keystone.user_list(self.request,
                                           domain=domain_id)
        group_members = self._get_group_members()
        group_member_ids = [user.id for user in group_members]
        return filter(lambda u: u.id not in group_member_ids, all_users)

which is in: dashboards/identity/groups/view.py

You can see that they are getting all users in the same domain as the group. The problem of Horizon is that you really don't want to say "get me all users in the system", since for most deployments this is a huge list. For horizon to add this, they would need to allow you to specify the domain you wanted to look in (and maybe part of the name of the user to look for), to make this tenable.

I suggest you raise this as a bug with Horizon to confirm that my hypothesis is correct,

[Bajarang Jadhav (bajarangmca)]

@Henry Nash (henry-nash),

I have raised bug in Horizon
https://bugs.launchpad.net/horizon/+bug/1476213

[Adam Young (ayoung)]

Henry, that was never part of the design; users and groups come in from the IdP, and are expected to be in the same domain. I am worried about what will happen with both LDAP and Federation here; in both those cases, users are expected to be in the same group.

However, the SQL backend may very well allow this. If so, we should be able to point at the unit test that tests it. Do we have one?

As far as I understand, however, users and groups have to be in the same backend.

[Bajarang Jadhav (bajarangmca)]

@Adam Young (ayoung),@Henry Nash (henry-nash),@jiaxi (tjxiter)

when will you fix this bug..

[Morgan Fainberg (mdrnstm)]

As a related point, there has been a RFE to allow for users from one backend to be placed in the group of another backend. As I recall this is related to the follow use-case:

LDAP / AD groups are not usable to Keystone (they are organization managed and do not match anything useful) and the OpenStack Cloud Admin wishes to use groups from within Keystone to manage grants.

This bug is semi-related in that if we pick one side or the other it will resolve the issue/make it more pronounced.

[Henry Nash (henry-nash)]

So, to sumamrize:

1) I do think it was part of the design - we deliberately, maybe incorrectly, tried to NOT limit membership when user groups were first implemented. But to young's point, there aren't any tests that I can see that defend this. I think we need to look at where/why people would need this - and if we think it isn't useful and/or dangerous try and deprecate it (over many cycles)

2) In the Federated case, I can imagine a common scenario being that groups are simply used as a mapping vehicle and don't have any non-ephemeral users - so whether we support mapping of user from one domain to a group in another domain is driven by the federated mapping rules.

3) In the non-federated LDAP/AD scenario, I do see the argument for having groups in Keystone that are used for assignment grouping - and these are different from those that come from the LDAP for that domain. We currently don't support this - and I'm not sure how we would (easily). I am sure the argument from some would be....if you really want this functionality then use the Apache LDAP mapping module, rather than the LDAP drivers in Keystone (and then Keystone can hold your "assignment groups" in SQL). I think I could be persuaded that this is the right answer - in which case we should move heavily test this scenario as an extension of our federation testing.

[Adam Young (ayoung)]

Works as designed and specified. The Wiki is wrong. Would not modify away from the existing behavior, either.