Hi everyone,

Just letting you know that we've updated the current Atlassian status in the description of this issue, and you should go check it out!

Eugene Mak
Atlassian Product Management

Crowd manages groups and roles for other applications. Can it not use its own infrastructure to support this feature? Delegated administration would be extremely helpful in large organizations where groups should be able to manage local and application-specific userids, but not view or modify the connectors, remote directories, etc.

a big +1 for delegated administration!

We're not going to be able to tackle this for the 2.0 release. To implement it properly, we'll have to significantly enhance our Role-Based Access Control (CWD-931), and that makes this feature too large to fit into the 2.0 release.

Apologies for the delay.

This is pretty crucial for us at Cornell as well. We currently are in a pretty good delegated administration model in Confluence, our largest installation, with the use of the Custom Space User Management plugin (delegating user creation and group membership administration for a predetermined set of groups per space). However, it sounds like if we implement Crowd to consolidate Confluence and JIRA user management, we may actually go backwards and lose this delegated administration capability we already have in Confluence.

Fixed Graham's comment

Sorry about above. Textile borked my comment a bit. Ignore the strikethrough

Just to let everyone know where we're at, and I think what we're doing would be doable in the Crowd console someday...

We're writing a webapp to do some common management tasks in Crowd, particularly bulk adding of users to a group (as opposed to groups to a user). We're limiting access based on a naming scheme, but an even better way would be to do so with ACLs.

All our groups and have a prefix, eg: CROWD-administrators, CROWD-users, JIRA-administrators, JIRA-users, MYAPP-administrators, MYAPP-users, etc. Our app grants access for a user to manage all group memberships beginning with the prefix if the user is in a -managers group. So a user in the MYAPP-managers group has access in our app to manage memberships to all the groups beginning with MYAPP-. A user in the MYAPP-administrators group can create and delete groups beginning with the MYAPP- prefix, as well as manage memberships. Users don't even see groups with a prefix to which they don't belong to the managers or administrators group.

It's a simple convention that allows us to quickly delegate users to manage memberships. Because we are using Crowd for authorization as well as authentication, each of our in-house applications has -administrators, and -users groups (among others) and by using a prefix we can easily fish out the groups pertinent to a particular application in a hurry. (This also is a poor man's way of giving a hierarchy to the list of groups.)

As I said, ACLs would be deluxe, but following some conventions can get you by until something like that gets done.

I would like to use Crowd to manage access for customers accessing my website. Customers need the ability to add/remove their own users.

We're likely going to write a quick webapp to implement something like this for our org, but I think it's definitely something that should be considered for addition natively to Crowd. It would be quite a feather in Crowd's cap, along with nested groups/roles.

Like you guys don't have enough on your plate already