-
Bug
-
Resolution: Fixed
-
Medium
-
2.7.1
-
None
-
None
Crowd should amalgamate all group memberships for the same username across multiple directories. This works when querying the members of a group, but not when querying the group memberships of a user.
This works (pseudo-code):
crowdGroup.getUsers();
This does not:
crowdUser.getGroups();
Here's the offending REST endpoint:
localhost:4990/crowd/rest/usermanagement/1/user/group/direct?username=user1&start-index=0&max-results=-1
What this can mean in downstream applications is that all groups are amalgamated when a user logs in to Confluence, but when they log in to the admin console, they only get the memberships from the top directory in Crowd. This has caused problems for users where their confluence-administrators and jira-administrators groups are in the second place directory, and logging in to the admin console means they lose these groups and authentication fails.
- is related to
-
CWD-3870 As an admin, I want to choose the membership aggregation semantics I want for each application
- Closed
-
EMBCWD-961 Failed to load
- relates to
-
- Closed
-
LEM-233 Failed to load
- mentioned in
-
Page
Failed to load
-
Page Loading...
-
-
-
-
-
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[CWD-3796] Group amalgamation behaviour is inconsistent in Crowd
Do we have a guess as to the date for Crowd 2.8.0? Is it going to be released before 2015?
Thanks
Daniel
Hi iiro.niinikoski, we are working to release Crowd 2.8.0, but haven't announced a release date.
Iiro Niinikoski
added a comment - Hi,
any ETA for Crowd 2.8.0?
Yours,
Iiro Niinikoski A fix has been developed for this issue and will be included in Crowd 2.8.0. Please stay tuned for updates, since some action by the admin may be required to correctly apply the fix.
Hi Helen,
Do you have any ETA on this? We have had 2 more users succumb to this issue, whereby they have no permissions to do anything except view tickets.
It is critical for us that we get this resolved as soon as possible, as our users rely on JIRA in their day to day roles.
Please let me know.
Regards,
Michael
Hi everyone,
Sorry for problems caused by this bug, we have spent some time exploring our options and will be beginning work very soon on this.
We have decided to improve the way Crowd does membership aggregation so that it works consistently and correctly. We will be implementing a configuration setting that will allow you to configure membership aggregation for your instance. This is because we have a fair share of customers that require it to be aggregated, and a portion that does not.
Thanks everyone for your continued support and patience on this issue. This fix involves quite a bit of testing in order to ensure that any area that involves memberships will work correctly with this configuration in place. We're doing our best to resolve this as quickly as possible.
Cheers
Helen Hung
Product Manager
Just an addition that this is progressively affecting more and more of our users, and is extending beyond users in the admin group.
One of our developers approached me today regarding his JIRA access. He is a member of the regular AD user groups (non-admin), and he cannot update, assign or comment on any cases.
I have looked at crowd and can confirm the groups are coming as far as crowd.
As our devs are using JIRA on a daily basis this is extremely urgent, we cannot afford to have this issue continuing.
Evgeny Minkevich
added a comment - I believe it takes a bit too long to address a critical regression within a security domain that affects multiple products.
The first attempt at fixing (CWD-3764) did not completely succeed and the second attempt (this) still sits in the backlog.
While the support staff was exceptionally helpful in reproducing the issue and tracing down the root cause I feel that the development scheduling process neglects the problem beyond reasonable. Could we please have a look and re-evaluate?
Evgeny Minkevich
added a comment - I believe it takes a bit too long to address a critical regression within a security domain that affects multiple products.
The first attempt at fixing ( CWD-3764 ) did not completely succeed and the second attempt (this) still sits in the backlog.
While the support staff was exceptionally helpful in reproducing the issue and tracing down the root cause I feel that the development scheduling process neglects the problem beyond reasonable. Could we please have a look and re-evaluate? We're considering how to fix this problem. The current consensus is to add a new property to Crowd applications to let them chose whether they want to aggregate memberships or not. At the same time, we'll fix the current implementation so, when the option to aggregate memberships is active, results delivered by Crowd are consistent, no matter how the query is formulated.
In that way, applications (and therefore, customers) will be able to chose the behaviour they want.
Crowd 2.8.0 was released yesterday: https://confluence.atlassian.com/display/CROWD/Crowd+2.8+Release+Notes