How To Add A User In A Particular Group In Aem

In my previous article, Improving Bulk User Cosmos in AEM 200x, I discussed how we improved a process importing thousands of groups and users into Adobe Experience Manager. This drastic speedup enabled our project to pass the development tests and nosotros looked good going into production.

Unfortunately, as soon as nosotros got access to the production user set up, we ran into some other operation trap. Our non-production information set had approximately 2,000 groups, while production had more than than 4,000. Fifty-fifty worse, there were a factor fewer user <-> grouping associations in non-production. The production data had nearly 100,000,000 user <-> group associations, while non-production only had less than a 10th as many.

While our user cosmos task would complete in approximately 30 minutes, the task to synchronize group members took over a week to complete.

Observing the task execution, the job always followed the same design, the job would make hundreds of changes / 2d for approximately the first 30 minutes, completing up to half of the updates, but then performance would drop, leading to only a scattering of updates per second for the remaining execution time, which took days.

Graph of Updates over Time

Our offset endeavour was to optimize the existing lawmaking, however pretty soon we found that micro-optimizations weren't going to get u.s. past the blocking trouble, information technology took too long to add together the members to the group, so we got artistic on looking for different solutions.

Solution Attempt #1 – Multi-Threading

Our outset fix endeavour was to create multiple threads, each to handle the membership for a single grouping, thinking that the problem was that at that place were particular groups causing the performance problems and if nosotros could get effectually those groups, we could resolve the effect.

On our local environments, against the not-product information, this seemed similar a fix, however, it was shredded when running confronting the production data set and indeed ran worse than our initial single-threaded solution.

Interestingly, nosotros found that this actually causes meaning I/O blocking due to excessive reads, unfortunately, our limited monitoring was non able to make up one's mind whatwas being read so much.

Solution Attempt #2 – importXML

Knowing that nosotros were facing an I/O problem, we looked into options to reduce the corporeality of I/O. After investigation of the Jackrabbit Oak code, nosotros found Grouping.addMembers was traversing the full group membership on each add to detect if the Authorizable was already a member of the group.

To convalesce this, we investigated using Workspace.importXML to instead import a fully-formed Sysview XML representation of the group and the grouping's membership.

Once once again, this showed tremendous hope during local tests:

Graph of importXML Perforamance

And once more, when faced with product data, importXML was reduced to a crawl. While faster, information technology withal took days to complete, well outside our three-hour window.

Eureka! Dynamic Group Membership!

While this is going on, we'd been steadily escalating through Adobe, eventually getting fourth dimension with Adobe Engineering in Basel. 1 the call, Adobe Engineering dropped a bomb, this is a known issue with AEM.

The issue is with the number of user <-> group connections. Specifically, with how Jackrabbit Oak internally uses indexes to store the grouping membership and is non something we could optimize. After some back and forth, the Adobe Engineering team suggested Dynamic Group Membership as an alternative solution.

Dynamic Group Membership works entirely differently than the default Jackrabbit Oak Group Membership. In Dynamic Grouping Membership, the user's groups are stored in a property rep:externalPrincipalNames and resolved at runtime.

This arroyo eliminates the need to add the users to the groups, thus resulting in a massive operation increase.

The best thing is this selection is easy to configure, set theIdentity Sync Type in the Adobe Granite SAML 2.0 Authentication Handler OSGi configuration tooak external idp sync for SAML-based authentication. For LDAP-based authentication, check theUser Dynamic Membership checkbox in theApache Jackrabbit Oak Default Sync Handler for your LDAP configuration.

One time you have configured Dynamic Group Membership, existing relevant users will need to be re-synced (eastward.g. deleted and re-added) as the default Jackrabbit Oak Group Membership volition take precedence.

Configuring the Granite SAML Authentication Handler

What if the Group Membership isn't in the IDP?

The default implementation of Dynamic Group Membership, every bit implemented in the Granite SAML Authentication Handler, assumes that the SAML Assertion contains all of the relevant data, including the group membership.

Unfortunately, in our case, the group membership is not stored in Active Directory every bit the Agile Directory is used corporation-wide, whereas these groups were specific to our application. This presented a problem as the rep:externalPrincipalNames attribute is protected at the JCR level and can only be accessed past whitelisted services.

Enter the Principal Provider

Under the hood, Dynamic Grouping Membership registers a PrincipalProvider service to expose the user's group membership based on the user'due south rep:externalPrincipalNames aspect. The Principal Provider interface is part of Jackrabbit Oak'due south Principal Direction API. Principal Provider implementations are chosen to betrayal principals (users and groups) and their group membership.

To back up having the group membership external to the SAML Exclamation without having to overlay meaning portions of the Granite SAML Authentication Hander, we just had to implement our own Principal Provider example. To avert impact during deployments, we implemented this equally a separate bundle from the chief projection code and had the bundle'south Activator set the parcel Kickoff Level to 15.

Diagram of the User Group Synchronization Solution

What does this hateful for me?

For AEM customers who need to support large numbers of users/groups (100,000+ users, 2,000+ groups) switching to Dynamic Group Membership volition significantly reduce the time required to synchronize the users and groups versus default Jackrabbit Oak group membership.

Using the PrincipalProvider / Principal Management API, you can even support providing group membership beyond what is available from the IDP.