Read Authentication and Authorization and then come back to this document.
Jive SBS doesn't support any out of the box. However, we provide an example SSO plugin to ease implementation of this. See the explanation in Authentication and Authorization, and get the code from subversion here. Reading over this code and this document is the best way to see how it's done.
You can as of version 2.5.x.
If you used Jive Forums and version 1.0, you'll be familiar with the AuthToken, which was manually passed around into our proxy layer to check permissions. In 2.x, you no longer have this AuthToken to pass around. You have an Authentication object stored in your SecurityContext, automatically stored there for you and accessible everywhere.
Here is an example of how to get your current context
SecurityContextHolder.getContext().getAuthentication();
There is a class dedicated to doing this called the SystemExecutor. Here is an example of
SystemExecutor exec = new
SystemExecutor<Boolean>(this.authProvider);
Callable<Boolean> callable = new Callable<Boolean>() {
public Boolean call() throws Exception {
boolean result =
registrationManager.validateAccount(userIDFinal, validationFinal);
return Boolean.valueOf(result);
}
};
success = exec.executeCallable(callable);
If you're using Spring to inject beans into your context (object) then you can trust that you have secured objects. CS implements security by wrapping your objects in a proxy layer that handles permissions. If you access Jive services directly through JiveApplication, use JiveApplication.getEffectiveContext() to get objects that are appropriately proxied. In most cases you don't want to create your own Jive domain objects (such as Blog, BlogPost); you will almost always obtain those through a manager. There are very few cases where you'd want to instantiate your own objects, and if you do be very sure you're securing things to check appropriate permissions. The Action classes like CreateBlogPostAction, CreateDocumentAction is often the best reference for seeing how to create domain objects securely.
This is destined to be the permissions system of the future. It's already in place for blogs. It's fully functional, so it would be a good place to implement permissions for customizations or new content types. A good place to look to understand the API is the BlogPermHelper, or the set of functional tests for the API.
We've centralized all permission logic in the system into a set of classes called *PermHelper, e.g. BlogPermHelper, JiveContainerPermHelper, ProjectPermHelper. The proxy layer makes calls into these to do the checks.
For both DWR and web services, authorization checks are made at the proxy layer. DWR uses the same authentication session as the main web application. REST uses basic HTTP auth by default. In general, web services try to authenticate each request.