User and group synchronization between JIRA/Confluence crowd database tables and Crowd

[Archanaa Panda]

Hi,

I would like to understand why JIRA and Confluence synchronize the users and groups in their own database with the crowd directories that they are mapped to.

1. Why are users and groups synchronized in database of the JIRA/Confluence application when they are also cached in ehcache.

2. Does it (synchronizing to app database) improve availability or performance? If so, for which specific operations?

3. Don't the applications send requests to the connected crowd always when a user tries to login to the application? Do they use the internal database itself to authenticate / authorize users and groups some times?

3. What happens if the mapped directory is a delegated authentication directory? Is there still synchronization done between embedded crowd of application and the crowd directory?

4. Is there a way to turn off synchronization completely between application's database and the crowd directory and if so, when is it recommended / not recommended to do so?

We have seen intermittent problems that incremental synchronization between JIRA/Confluence with Crowd fails due to duplicate keys.

We are using - JIRA 5.1.2, Confluence 4.3.1 and Crowd 2.4.2. We are still investigating when these synchronization problems occur, but what I wanted to understand is if it is an optional thing to synchronize with the application database at all.

[fsim · Accepted solution]

Hey Archanaa,

{quote}
1. Why are users and groups synchronized in database of the JIRA/Confluence application when they are also cached in ehcache.
{quote}
ehcache cannot have too many elements in memory, and for this reason alone, it makes complete sense to store user elements in the database. It also does not make sense in terms of memory usage to cache all users and groups into the memory.

{quote}
2. Does it (synchronizing to app database) improve availability or performance? If so, for which specific operations?
{quote}
There are many operations in JIRA/Confluence that constantly requests data from the userbase, such as indexing for the User Picker/People Directory, permissions checking for content (determining whether a user is member of a certain group before allowing access to the content), or to calculate licensed users (which is what Confluence constantly runs whenever a user logs in, or whenever a user tries to edit a document). Constantly querying Crowd for these sort of information will ultimately break Crowd.

{quote}
3. Don't the applications send requests to the connected crowd always when a user tries to login to the application? Do they use the internal database itself to authenticate / authorize users and groups some times?
{quote}
Yes, you are right here, authentication is always delegated to Crowd (no authentication in the internal database). Authorization however, as what I mentioned above (permissions checking, etc), is done in the internal database of that app

{quote}
3. What happens if the mapped directory is a delegated authentication directory? Is there still synchronization done between embedded crowd of application and the crowd directory?
{quote}
Yes, even if the mapped directory is a delegated directory, a Crowd sync will still need to be triggered, which is a common limitation reported by our customers (when a delegated user tries to login to Confluence, he/she has to perform 2 attempts: 1 attempt will throw a failed login, which will bring the user into Crowd; Wait for the sync to be triggered, then login again).

{quote}
4. Is there a way to turn off synchronization completely between application's database and the crowd directory and if so, when is it recommended / not recommended to do so?
{quote}
This is not recommended (and not possible), we hardcoded our application to use the cwd tables in Confluence/JIRA to fetch users, etc. So doing so will break Crowd integration.

Hope this answers your questions! These are actually good questions. Thanks for bringing them up to us.

Thanks and Regards,
Foogie