We have a client whose needs include searching through community content from an external system. Jive's v3 RESTful web service API accommodates this, and it is through this mechanism that the external system invokes the search and retrieves results.
However, this client also requires that the search return results as if a named Jive user had actually performed the search. SearchQueryManagerImpl relies upon the wired AuthenticationProvider to retrieve the Jive User whose permissions are used to filter search results. When asked to retrieve the User, the wired AuthenticationProvider (an instance of SecurityContextAuthenticationProviderImpl) returns either the user associated with the active Spring Security authentication context or an anonymous Jive user. The user associated with the authentication context is the user whose credentials were passed when invoking the search web service. This is a user we have explicitly provisioned to invoke web services from the client's external system, not the user whose permissions are to be used to filter search results.
We have circumvented this problem by:
- Introducing a new query parameter on the /search/contents API. We can now specify the user whose permissions to use when filtering search results with ...filter=proxiedUsername(foo)
- Extending the SearchService to peel off and retain the proxiedUsername value from the query parameters before invoking its parent's searchContents() method. This username (and essentially the User associated with it) are maintained for the course of the search in a ThreadLocal value
- Extending the AuthenticationProvider such that when getJiveUser() is called, it first checks for the value of the ThreadLocal. If the value is set (with the "proxied" Jive user), it is this value that is returned. If not, the Jive user associated with the Spring Security authentication context is returned.
This mechanism is working great. However, it has required modifications introduced by means of a plugin. The client is currently on a hosted instance of Jive 6, so these customizations haven't presented a problem.
Our problem is that this client now wishes to migrate to a Jive 7 Cloud instance, where the opportunities for introducing such customizations will be limited. Our questions are:
- How will we be able to introduce this type of customization in a Jive 7 Cloud instance?
- Is this level of integration possible simply by developing Jive Apps and leveraging the Jive SDK?