HTTP Compression with Spring Security running on Sun Webserver

[charliefryer]

Hi there,

I have enabled compression on our sun web server 7 on HTTPS.

Static compression is enabled on all css and js files.

Dynamic compression is enabled on jsps and servlets.

Before we enabled compression, the website functioned correctly. However since enabling compression on files, Spring security is creating problems.

For example if a admin user is logged in, he loses his ROLE_ADMIN. There is no pattern to when this happens.

Sometimes he can log in, click on an admin link and get kicked out.

Other times he can log in, click around for a while and then admin links disappear.

I enabled Spring logging and can see the security context holder getting cleared.

It gives no reason as to why its getting cleared. The gz file is passing through the filter chain when this happens.

2011-12-05 15:38:29,907 DEBUG 786951 - SecurityContextHolder not populated with anonymous token, as it already contained: 'org.springframework.security.web.authentication.p reauth.PreAuthenticatedAuthenticationToken@74195c2 5: Principal: org.springframework.security.core.userdetails.User @61091700: Username: 786951; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_OWN,ROLE_PC,ROLE_ADMIN; Credentials: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: ROLE_ADMIN, ROLE_OWN, ROLE_PC'
2011-12-05 15:38:29,907 DEBUG 786951 - /css/password_style.css.gz at position 8 of 10 in additional filter chain; firing Filter: 'SessionManagementFilter'
2011-12-05 15:38:29,907 DEBUG 786951 - /css/password_style.css.gz at position 9 of 10 in additional filter chain; firing Filter: 'ExceptionTranslationFilter'
2011-12-05 15:38:29,907 DEBUG 786951 - /css/password_style.css.gz at position 10 of 10 in additional filter chain; firing Filter: 'FilterSecurityInterceptor'
2011-12-05 15:38:29,907 DEBUG 786951 - Converted URL to lowercase, from: '/css/password_style.css.gz'; to: '/css/password_style.css.gz'
2011-12-05 15:38:29,907 DEBUG 786951 - Public object - authentication not attempted
2011-12-05 15:38:29,907 DEBUG 786951 - /css/password_style.css.gz reached end of additional filter chain; proceeding with original chain
2011-12-05 15:38:29,908 DEBUG - Chain processed normally
2011-12-05 15:38:29,908 DEBUG - SecurityContextHolder now cleared, as request processing completed
2011-12-05 15:38:29,909 DEBUG - Chain processed normally
2011-12-05 15:38:29,909 DEBUG - SecurityContext is empty or anonymous - context will not be stored in HttpSession.
2011-12-05 15:38:29,909 DEBUG - SecurityContextHolder now cleared, as request processing completed
2011-12-05 15:38:29,916 DEBUG - Converted URL to lowercase, from: '/js/privateforms.js.gz'; to: '/js/privateforms.js.gz'
2011-12-05 15:38:29,916 DEBUG - Converted URL to lowercase, from: '/js/alerts.js.gz'; to: '/js/alerts.js.gz'
2011-12-05 15:38:29,917 DEBUG - Candidate is: '/js/privateforms.js.gz'; pattern is /**; matched=true
2011-12-05 15:38:29,917 DEBUG - Candidate is: '/js/alerts.js.gz'; pattern is /**; matched=true
2011-12-05 15:38:29,917 DEBUG - /js/privateforms.js.gz at position 1 of 10 in additional filter chain; firing Filter:

I’ve tried modifying the security context to ignore gz files but this didn’t help and I didnt think this would be the correct thing to do as it would allow jsps to bypass security!

In the application, we don’t use the standard Spring security login procedure.

We manually build the security context ourselves in a servlet.

ie
public void setContext(List<Role> ourRoles, String userId, String password){

logger.info("In SetContext");
SecurityContext context = new SecurityContextImpl();
logger.info("Created new Security Context");
Collection<GrantedAuthority> ga = new ArrayList<GrantedAuthority>();
logger.info("Setting roles");
for(Role role : ourRoles){
logger.info("Adding : " + role.getDescription());
ga.add(new GrantedAuthorityImpl(role.getDescription()));
}
logger.info("Finished setting GrantedAuthoritys");
User newUser = new User(userId, password, true, true, true, true, ga);
logger.info("Created new User");
Authentication auth = new PreAuthenticatedAuthenticationToken(newUser, password, ga);
logger.info("Created Authentication");
context.setAuthentication(auth);
logger.info("Set Authentication on the context");
SecurityContextHolder.setContext(context);
logger.info("Set New Security Context for user: " + userId);

}

I cant find much help with this on the net, I'd really appreciate any help or suggestions.

Thanks a lot,
Charlie.

[Rob Winch]

For example if a admin user is logged in, he loses his ROLE_ADMIN. There is no pattern to when this happens.

Does the user appear to be authenticated and just not have the correct access or do they just appear to have the wrong attributes?

I enabled Spring logging and can see the security context holder getting cleared.

The spring SecurityContextHolder should be cleared for every request. It is repopulated at the beginning of every request by looking up the value in session. Have you validated that the JSESSIONID is properly being returned? For example, if you view the requests/responses in something like Tamper Data do you see a consistent JSESSIONID?

I’ve tried modifying the security context to ignore gz files but this didn’t help and I didnt think this would be the correct thing to do as it would allow jsps to bypass security!

You could match on /css/** and /js/** to eliminate processing of css and javascript.

PS: In the future when posting logs or code use the code tags (i.e. the # button) as this makes the post easier to read

[charliefryer]

Thanks for that rwinch,

I have omitted css and js from the security filter and the authorisation is working properly.

This allows me to compress all css and js files which is great.

Thanks again,
Charlie.