Security: Frequently Asked Questions

    How do I learn about security, authentication and authorization, entitlements, and so on?

    Read Authentication and Authorization and then come back to this document.

    How do I learn about SSO?

    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.

    Can I deploy authentication and authorization as a plugin?

    You can as of version 2.5.x.

     

    Are we still using the AuthToken?

    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();
    

    I know what I'm doing and I'd like to make a call as a system user.  How do I do that?

    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);
    

    How do I ensure that my method calls are checking permissions properly?

    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.

    What is the entitlements API?

    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.

    What are the PermHelpers?

    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.

    What about security in DWR and web services?

    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.

    What are some other things I really should know?

    • It's rarely necessary to override  AuthToken and doing so will result in your needing to edit several classes, some of them Acegi classes.
    • If you choose to write an  AuthProvider, your auth provider will need to accept the  UsernamePasswordAuthenticationToken -- Acegi coerces all form-based authentication into an instance of that class.
    • If you implement your own filter, you will need to add your filter (after the  SessionContextIntegrationFilter) and may want to remove other authentication filters on the Acegi filter chain with the exception of the  following:
    •    httpSessionContextIntegrationFilter  
    •   rememberMeProcessingFilter -- leave if you wish to enable "Remember Me" authentication 
       
    •   feedBasicAuthenticationFilter -- leave if you wish to use Basic Authentication for RSS/Atom Feeds 
       
    •    exceptionTranslationFilter  
       
    •    jiveAuthenticationTranslationFilter