Comment 17 for bug 1474284

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.