Cosmo 1.0 Security Notes

Spring Security Framework

Cosmo 1.0 utilizes the spring security framework for authentication and authorization services. The FilterChainProxy groups all the necessary authentication and authorization processing logic. It is configured using spring and implemented as a servlet filter. Each protocol (dav/atom/morse code/etc) defines its own filter chain in its own spring configuration file (applicationContext-security-dav.xml, applicationContext-security-mc.xml, etc). For most cases the sequence looks like:

Authentication Processing Filters
Responsible for gathering authentication data (username/password/ticket/etc) and packaging into a common "Authentication request" object. For example, grap the Authorization header from an HTTP request, or look for username/password parameters from a HTTP form POST.

Exception Translation Filter
Responsible for catching security exceptions and deciding what to do with them (return 403 or forward to login).

Invocation Interceptor Filter
Responsible for authenticating (using AuthenticationManager) and authorizing (AccessDecisionManager) request. The request is authenticated and authorized using the data gathered from the authentication processing filters. Any exception thrown will be caught by the exception translation filter and handled appropriately. Cosmo uses spring security's ProviderManager as the AuthenticationManager, which authenticates using a number of AuthenticationProvider implementations including DaoAuthenticationProvider (for authenticating users from the db), TicketAuthenticationProvider (for authenticating requests containing a ticket), and AnonymousAuthenticationProvider (for allowing anonymous requests with no authentication).

Cosmo Security

Cosmo provides a CosmoSecurityManager , which is a facade for the Spring Security security context. All application logic uses an instance of CosmoSecurityManager for access to the current credentials. For more information refer to the org.osaf.cosmo.security.* packages.

Securing Service Layer

The ContentService is secured using a security aspect (aop) that is wrapped around each ContentService^? call. The aspect is defined in org.osaf.cosmo.security.aop.SecurityAdvice, and configured using spring. The security advice authorizes each method call based on the current security context, and throws an ItemSecurityException if the current context isn't authorized.

Securing Protocol Requests

All protocol requests (dav/morse code/atom/webcal/etc) are run through the above spring security filter chain for authentication and authorization (before being handled by the respective servlet) is handled as follows:

1. If the request is to a user resource, then the request is secured by the UserPathAccessDecisionManager in the spring security filter chain
2. If the request is to an item resource, then the request is not secured by spring security, but by the security aspect wrapped around the content service layer

Ideally, all authorization is done at the service layer, but UserService is not yet secured.

Item security Overview

The security policy for access to items can be summarized as:

read operations:

    if current context is admin, grant access
    else if current context is user and user owns item or one of item's parents, grant access
    else if current context is user and user has read or read-write subscription to item or one of item's parents, grant access
    else deny access

write operations:

    if current context is admin, grant access
    else if current context is user and user owns item or one of item's parents, grant access
    else if current context is user and user has read-write subscription to item or one of item's parents, grant access
    else deny access

Because the server allows items in multiple collections, it is possible for an item to have different permissions depending on what collections it exists in. One side effect of this is that once a user gains read-write access to an item, they essentially have full control over it and can add it to other collections and grant new tickets on these collections. This is a tradeoff we chose in order to make synchronizing items in multiple collections simple, that is, only keep one copy.

-- RandyLetness - 25 Jun 2008