Tricking the RemoteGroup

Last time I promised you to write of another useful trick that helped me optimize group queries in Atlassian Crowd.

If you've ever used Crowd web interface you would've noticed that, Crowd when querying for a group also retrieves a list of all the group members. It may be too much of an overhead to do it before even displaying group attributes. Fortunately there's a way to outsmart Crowd!

If you take a look at the RemoteDirectory interface, you'll be able to find those three methods:

1. public List<RemotePrincipal> findAllGroupMembers(final String groupName);
2. public RemoteGroup findGroupByName(String groupName, boolean onlyFetchDirectMembers);
3. public RemoteGroup findGroupByName(String groupName);

First one returns list of principals that are members of the group. Second and the third methods return an object representing group with the given name. Crowd uses latter methods when you click on group name in Crowd's web interface, it then displays a page with group description and its attributes. You may even not want to see the list of principals that is accessible through the Members tab.

Problem is that RemoteGroup instances returned by the second and third methods must already be populated with a list of members; otherwise Members tab will be empty. So there seem to be not much of a choice, either waste time querying for principals or have non functional connector.

Let's take a closer look at RemoteGroup, it has an interesting method setDirectory(Directory directory). It appears that Crowd uses this directory if it sees that the object is not fully initialized. Thus we can return an empty RemoteGroup instance with only group name and activity flag set. Later Crowd will do the following:

directory.getImplementation().findAllGroupMembers(...)

if it needs a list of members.

Here's my extension of the Directory class:

class ReferencingDirectory extends Directory {
  private static final long serialVersionUID = 1L;
  /**
   * Reference to the remote directory to avoid object creation.
   */
  private final RemoteDirectory remoteDirectory;

  public ReferencingDirectory(RemoteDirectory remoteDirectory) {
    Utils.checkNull("Remote directory", remoteDirectory);
    this.remoteDirectory = remoteDirectory;
  }

  @Override
  public RemoteDirectory getImplementation() {
    return remoteDirectory;
  }

  @Override
  public String getImplementationClass() {
    return remoteDirectory.getClass().getCanonicalName();
  }
}

I keep an instance of it in my implementation of RemoteDirectory and pass it to RemoteGroup whenever I need it.

That's it! Queries for groups are much faster now, and if really needed members are queried separately.

Atlassian Crowd Custom Directory

Today I chose to share with you my experience with implementing custom directory connector to Atlassian Crowd. There is a rather straight forward interface defined on Atlassian site which is not really hard to implement. What I would like to write about is a small number of tricks that helped me to achieve the desired results.

By the way, if you take a look at the Atlassian documentation you will notice that implementation among others should extend DirectoryEntity which is not completely true, for me it was more than enough to implement the RemoteDirectory interface.

No roles

Although notion of roles existed in my company's directory service still they were Windows specific and completely irrelevant to Atlassian products. I needed simple stub implementations of all the role related methods that would not break Crowd's work flow.

It was a good idea to return an empty list on findRoleMemberships(String principalName) method invocation, as throwing an exception would result in exception each time one would try to get principal's information on Crowd's site. Another method searchRoles(SearchContext context) was also better off returning an empty list instead of throwing an exception.

Legacy data

We had been using JIRA, Confluence, and Bamboo for several years and naturally user and group information hadn't been synchronized with the central directory. Our original intention was to integrate Atlassian tools as smoothly as possible, so for every tool I used a stack of two directories one of which was always a snapshot of the user information at the integration stage. Crowd was clever enough to merge data from both of them and it worked especially well for the users that chose same log-in names as in the company's directory, their group membership from the both directories was merged.

Note: order in which directories are listed actually matters, to use passwords from the central directory I had to put the custom directory first in the list.

Read-only

According to my company's safety rules I had to implement a read-only connector. So I chose to throw the UnsupportedOperationException exception when user attempted to update any information concerning principal, group or role. Crowd behaved very well whenever the exception was thrown.

Modifiable internal directory

I also wanted to allow administrators, from JIRA for example, to modify information in Crowd's internal directory. So my policy was following, throw ObjectNotFoundException exception if user and/or group didn't exist in the central directory, methods concerned were: addPrincipalToGroup, removeGroup, removeGroup, removePrincipalFromGroup, updateGroup, updatePrincipal, updatePrincipalCredential. In the other case methods defaulted to throwing UnsupportedOperationException exception. All this led to the next work flow (updateGroup is taken as an example):

• Invocation of updateGroup of the custom directory (CD).
• Group doesn't exist in CD, throw the ObjectNotFoundException.
• Crowd proceeds to the next directory, which is the Internal Directory (ID).
• ID processes the request graciously.

To achieve the aforementioned functionality with groups I simply called this.findGroupByName(groupName) and if it didn't throw an exception the method threw the UnsupportedOperationException. To check principal existence it was enough to call this.findPrincipalByName(name).

Here's an example:

public void addPrincipalToGroup(String name, String groupName)
 throws ObjectNotFoundException
{
 this.findGroupByName(unsubscribedGroup);
 throw new UnsupportedOperationException(CANNOT_EDIT_DIRECTORY);
}

In contrary to the given example if the group actually existed in the central directory UnsupportedOperationException was thrown which forced Crowd to stop processing the request. This perfectly corresponded to my wishes.

Conclusion

As the result I managed to keep the existing data in editable state merged with the central directory.

What I have described in this post doesn't go outside of scope of abstract implementation of RemoteDirectory which I called ReadOnlyRemoteDirectory. Someday I will describe another trick that helped me minimize the group retrieval delay.