Grails Spring Security using PreAuthenticated Authentication Provider

May 26, 2011 11:09 am

This was a tricky problem I’ve been trying to solve for a little while.

If your webserver is providing the authentication service then your application simply needs to read in the `remoteUser` value out of the request header and trust it. In Grails you can do this with the Spring Security Core plugin using a PreAuthenticatedAuthenticationProvider. But it requires some configuration.

Follow the regular Spring Security Core setup process with the following adjustments.

In Config.groovy, define the providers you want available:

grails.plugins.springsecurity.providerNames = ['preAuthenticatedAuthenticationProvider', 'anonymousAuthenticationProvider']


And we need to define that preAuthenticated provider as a bean.

In resources.groovy we need:

beans = {
userDetailsService(org.codehaus.groovy.grails.plugins.springsecurity.GormUserDetailsService) {
grailsApplication = ref('grailsApplication')
}

userDetailsByNameServiceWrapper(org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper) {
userDetailsService = ref('userDetailsService')
}

preAuthenticatedAuthenticationProvider(org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider) {
preAuthenticatedUserDetailsService = userDetailsByNameServiceWrapper
}

requestHeaderAuthenticationFilter(org.springframework.security.web.authentication.preauth.RequestHeaderAuthenticationFilter) {
principalRequestHeader = 'remoteUser'
authenticationManager = ref('authenticationManager')
}
}


And finally, in our BootStrap.groovy file we need to register the authentication filter:

import org.codehaus.groovy.grails.plugins.springsecurity.SecurityFilterPosition
import org.codehaus.groovy.grails.plugins.springsecurity.SpringSecurityUtils

class BootStrap {
def init = { servletContext ->
SpringSecurityUtils.clientRegisterFilter('requestHeaderAuthenticationFilter', SecurityFilterPosition.PRE_AUTH_FILTER)
}
}

While on a hike

May 22, 2011 4:07 pm

Yesterday I convinced Jess to go for a hike with me up at Del Valle Reservoir. It’s a nice area just outside of the Livermore city limits. I haven’t done anything outside in awhile beyond driving to/from work (or bicycling the same occasionally) and I wanted to be outside since it has been nice out.

So yesterday we drove out to the reservoir and did a short hike, about 1.2 miles. We stopped about halfway through and rested. While resting I took a bunch of pictures, none of which quite turned out how I had imagined. The wind was blowing rather strongly, so I thought it might be fun to try and get a picture of the tall, dry grass covering the hills blowing in the wind. Kind of like the kind of pictures you can get of water where it looks silky. Well, that didn’t quite work out, it mostly looks like a blurry mess, but I was able to adjust one to look kind of nice. I used an oil painting effect to get a somewhat impressionist version of the hillside. It looks okay, but there’s nowhere really for your eye to settle.
IMGP4804_cropped_sAs we began hiking again we passed a bunch of thistles. We happened upon one that was growing all by itself which presented a nice opportunity to get it isolated from the background. As I mentioned, the wind was blowing so I didn’t have much control of the exposure besides cranking the shutter speed up as fast as it would go in order to keep it from blurring. This also meant I needed to bump up the ISO, so the shot came out a little bit grainy, but I think it still looks pretty good:
IMGP4859_sharpenedAfter the hike we stopped at Wienerschnitzel for some ice-cream. On our way to the reservoir we had seen that they were selling 79-cent soft-serve ice-cream cones. Jess, however, opted for a caramel sundae instead. Regardless, the ice-cream was good. I would be more than happy to make a regular thing of hiking / photographing for 1.5-2 hours and then getting ice-cream.

Melancholy Meerkat

May 16, 2011 9:23 pm

I submitted a picture from our trip to the San Diego Zoo to the Intermediate Pictorial category of our camera club this week. This year there have been a lot of good photographers in the intermediate group. Some months I disagree with the judge and the pictures that place. However, as we were going through the images this week I was thinking there were many very good pictures and that I wouldn’t feel grumpy about them being placed over mine. When my picture was shown the judge didn’t have any critiques about it, but also moved along fairly quickly without much comment. So I was actually quite surprised, and very flattered, when it was awarded first place.

I do rather like the photo. But I don’t claim to be able to find and take shots like this with any regularity. Of the 328 pictures I took at the zoo this is the only one that I still really liked after I worked with it. So I’d like to show a few of the steps this image took before the finished product.

Top-left: The original image as it came off the camera.
Top-right: The first step was to take out the extra blue. Your eye is very good at making you think the color balance is OK, but when you see the image with the blue removed it looks much better. The only thing done between the original and this image is the removal of the extra blue.
Bottom: Then I cropped in on the face and bumped up the contrast a little, the saturation a little, and removed some distracting blobs in the background.
IMGP4675_123The final step was to add some selective darkening to tone down overly bright areas and help the eye stay focused on the face. Here is the final image:
IMGP4675_4

Check forgery protection using public-key cryptography

April 11, 2011 8:31 pm

Mom forwarded an email that was attempting to scam her in response to a Craigslist ad she placed for some furniture.

While I was thinking about this I realized we have the ability to essentially stop check forgery, specifically cashier’s checks and money orders, but the principle would also apply to personal checks if we could develop a trusted lookup source for public keys.

Public-key cryptography allows you to publish a public key that can be used to either verify that you digitally signed something with your private key or to encrypt something which can only be decrypted with your private key.

The application would be as follows.

First, the banks put together a trusted database of public keys. This part is essential, as it must be possible to lookup a public key for any bank and you need to have a trusted source where at you do the lookup. A central database is mainly a convenience factor, you could simply have each bank publish their public key on their own site, but a more integrated solution is more likely to be used. This is not an insurmountable hurdle.

Second, when a bank creates a cashier’s check it uses the data on the check (name, amount, date, etc.) and their private key to produce a digitally signed digital copy (or digitally signed hash) of the data which could be printed directly on the check as a QR code (or set of QR codes depending on size) [QR codes are those square barcodes].

Third, when someone attempts to cash the check the cashing bank scans the QR code(s) and verifies that the data matches what’s printed on the check and also looks up the public key of the issuing bank and verifies that the signature is legitimate. In fact the actual printed data would be unnecessary at this point if it was encoded in the QR code, but I imagine we’d want to leave it on for the sake of the humans handling the check.

That’s it. If implemented correctly and securely it would guarantee the authenticity of cashier’s checks. The same system could be used for money orders as well. The other great thing about it is that individuals could verify a check the same way. They could scan the QR codes themselves with their fancy phones and then lookup the bank’s public key (either from a trusted central repository or from the individual bank) and verify the authenticity of the check without any risk.

The biggest hurdles would really be getting a trusted repository set up and having banks securely store their private keys. There are easy extensions making this process even more feasible. You can use a master key to create sub-keys which could be used by individual branches. That would limit the risk if any individual branch’s private key were compromised. With a central repository a compromised bank would revoke the published public key and flag it as compromised. Any outstanding checks would need to be brought back to the issuing bank to be reissued using a new key. A hassle, but it should be a world-shattering occurrence for a private key to be compromised.

This system is totally possible with today’s technology. It would just be a matter of setting it up and getting banks to participate. Maybe I should go talk to some venture capitalists…