Delegated Authority vs ldap connection

[Reil Reil]

Is there a standard rule of thumb for the number of users that one should have in ldap to determine if you use delegated authority vs a standard ldap connection?

The reason I ask is that in the new confluence and jira they are recommending a delegated authority be setup, but crowd support has mentioned that delegated is best for 10000+ users. We have 6000+ allowed to use confluence from a ldap server with 150000+ users so we initially setup crowd with delegated authority and used a script to keep the directory in-sync with changes in the ldap. But with the upgrades to 2.2.X the scripts fail and changes have become problematic. So we need to decide do we drop Delegated and go to the ldap connection or do we stay on delegated and keep hacking at this script.

Thoughts?

[Penny Wyatt (On Leave to July 2021)]

I don't claim to be an expert on Crowd, but for a userbase of 150000+ users (even if only 6000+ are being used in the app), I believe delegated LDAP is the way to go - otherwise you could end up with all 150000+ users making the Crowd directory unnecessarily large.

It doesn't sound good that you need to hack scripts, though. What changes do you need to sync in the directory when working in delegated LDAP? I ask because if it's just user creation, the users should be automatically created in Crowd when they first log in.

http://confluence.atlassian.com/display/CROWD/Configuring+a+Delegated+Authentication+Directory

Relevant part:

Consider how you would like to add your users to Crowd's Delegated Authentication directory. There are a few options:

...

* Let Crowd do it for you, at login time. If a user logs in successfully via LDAP authentication but does not yet exist in Crowd, Crowd will automatically add them to the Delegated Authentication directory. You will then need to add the user to any necessary groups, to allow them to access applications where group membership is required.

[Reil Reil]

The script we have is really centered around group-membership. We use group membership to control access to both Jira projects and Confluence spaces. But there are so many groups 150+ for both confluence and jira that the auto add feature wouldnt work. We can grant everyone a simple confluence-users or jira-users membership but the groups are also the format of GP-CFW-BLAH GP-JIRA-FOO GP-JIRA_BLAH even the unforgiveable GP_ CFW-FOO (note the space and the bloody underscore)

In 2.0X the script would check the LDAP and the CROWD see if there were new groups in LDAP with the format and create them in Crowd and then populate them. Then it would add the users to to CROWD if they were in the groups in LDAP but not in Crowd and then it would add the users to the group. It would also do deletes. But the changes in 2.2.X changed such that the operation had to be run per application instead of directory wide on Crowd.

I just tried a new LDAP Connection but what I see is the Synchronization takes 12 hours. And the groups are not created and users are not populated in the groups so no login occurs. I also tried allowing All users to connect to an application from the directory but that too fails.

When I add the groups to the application in the LDAP Directory on crowd set all to false, the users can login but thats unwieldy because groups are created and changed all the time.

[Penny Wyatt (On Leave to July 2021)]

Ouch; I see. Sorry I can't help, hopefully someone else can.