a regular expression

Careful With Your Binary Resources!

November 4, 2009 · Leave a Comment

Our production application stack has a fair amount of external service connections that require the use of certs for SSL security. We used to use a static reference (e.g. /config/certs or c:\config\certs for you Windows people) to locate the certificates, but this was always suboptimal as it made the application less portable. I finally got around to moving from the static reference and landing on Java jar introspection to find the file (using something similar to ClassName.getResource("/cert.pks");).

This conversion worked very well and everything seemed fine until the change got to our continuous integration (or CI) box. That machine, a Centos distribution, kept failing with the error Invalid keystore format when we tried to initialize the keystore in code. I spent hours trying to figure out the difference between my local machine (running OS X, which worked fine) and the CI box. I finally diff’d the cert file in src/main/resources and the resulting file in target/classes. I discovered that the two files were radically different.

Maven has a very cool feature that not only copies values from src/main/resources into target/classes and, ultimately, the resulting Jar file but also can substitute tokens in text files as part of the build (referred to as “filtering”). To enable this, all you have to do is add

<resources>
            <resource>
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
            </resource>
</resources>

to your pom.xml file and you’re off to the races. However, Maven will process every file in the src/main/resources directory as part of performing this substitution. This normally wouldn’t be an issue, but certificate files contain some raw text and Maven dutifully filters them just as it would any resource. This caused a serious issue with the character encoding as Maven was writing out a file with a completely different encoding scheme than the file was created with. Basically, Maven filtering was corrupting our certs.

To fix this, I created a subdirectory off of src/main/resources (I called it binary) and added a manual exclusion in the pom.xml file. The resulting XML looks as follows:

<resources>
            <resource>
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
                <excludes>
                    <exclude>**/binary/*</exclude>
                </excludes>
            </resource>
            <resource>
                <directory>src/main/resources/binary</directory>
            </resource>
</resources>

This worked perfectly. Hopefully, it helps some of you as well!

→ Leave a CommentCategories: Java · Programming

Grails Acegi Plugin and Securing Multiple Resources using Basic Authentication

October 29, 2009 · 1 Comment

Grails is pretty awesome. Not only does it use Groovy as its main language, but it also provides nice DSL access to Spring settings.

Securing a website is something that can often be fairly complex and easy to get wrong. Grails provides a plugin for the state-of-the-art security model Spring Security (also called Acegi) (plugin can be found here).

Everything was all well and good until I tried to use two different security models simultaneously: a form-based login for human beings and an http basic authentication login for machines consuming an API.

This turned out to be pretty hard. The plugin requires setting the following in the resources.groovy file to work with basic authentication at all:

beans = {
  authenticationEntryPoint(org.springframework.security.ui.basicauth.BasicProcessingFilterEntryPoint) {
    realmName = 'Grails Realm'
  }
}

(The plugin is supposed to automatically do this by setting the basicProcessingFilter = true flag in the SecurityConfigure.groovy file, but there is a bug as of version 0.5.2 which is, as of now, the latest production release.) This worked for basic authentication, but would no longer redirect users to the form-based login.

Back to the drawing board.

What I discovered was that I could change between using the form-based login or the http headers authentication but not use them both. (I should clarify this by saying that I could shove the headers into the request and it would work, but a challenge response of 401 was not being sent back to the client which technically breaks the http authentication spec.) I found this thread (with contributions from the author of the Acegi plugin itself) but, while it pointed me in a nice direction, it didn’t answer the question fully. What I really needed was a way to use the URL to decide how to authenticate.

I finally discovered that the ExceptionTranslationFilter was not unique for the URLs I was using. In short, if the URL looked like: http://www.test.com/application/api/user/show/1, I wanted to use basic authentication and if the URL was http://www.test.com/application/user/show/1, I wanted to use the form-based authentication. The redirect is controlled by the ExceptionTranslationFilter and there was only one (so only one model would work at a time).

All I ended up having to do is create my own ExceptionTranslationFilter and wire it to the API URL. The final code in resources.groovy looks as follows:

import org.springframework.security.util.FilterChainProxy
import org.codehaus.groovy.grails.plugins.springsecurity.GrailsAccessDeniedHandlerImpl
import org.springframework.security.ui.ExceptionTranslationFilter

// Place your Spring DSL code here
beans = {
  basicAuthenticationEntryPoint(org.springframework.security.ui.basicauth.BasicProcessingFilterEntryPoint) {
    realmName = 'Grails Realm'
  }

  basicExceptionTranslationFilter(ExceptionTranslationFilter) {
    authenticationEntryPoint = ref('basicAuthenticationEntryPoint')
    accessDeniedHandler = ref('accessDeniedHandler')
    portResolver = ref('portResolver')
  }

  springSecurityFilterChain(FilterChainProxy) {
    filterInvocationDefinitionSource = """
         CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
         PATTERN_TYPE_APACHE_ANT
         /xml*/**=authenticationProcessingFilter,basicProcessingFilter,securityContextHolderAwareRequestFilter,anonymousProcessingFilter,basicExceptionTranslationFilter,filterInvocationInterceptor
         /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
         """
  }
}

Now, visiting any URL that prefixed by a /xml/ will be a call to the basic authentication headers and every other prefix will be a standard form-based login.

Since I shaved a serious yak figuring this out, I hope it helps someone!

→ 1 CommentCategories: Grails · Java · Programming

Staying Together for the Kids

September 22, 2009 · Leave a Comment

After the church I was involved with fell apart a couple of years ago, a group of us from the music team continued to meet and play together. Occasionally, we’ll get calls from other churches asking us to fill in for their Sunday service and give their worship team a chance to take a break (playing week-in / week-out can get tiresome and often strain volunteer musicians to an emotional breaking point).

One church we recently had the pleasure of subbing for is in the middle of a church split due to the recent vote by the ELCA (Evangelical Lutheran Church in America) to allow for those in “life-long, monogamous, same-gendered” relationships to serve in leadership positions (find out more at http://www.washingtonpost.com/wp-dyn/content/article/2009/08/21/AR2009082103343.html). For those who don’t know, the ELCA is the largest Lutheran denomination in the United States and has classically been a bit more liberal than other Lutheran organizations. The provision does not require churches to accept homosexual ministers but allows for churches that desire integration of same-sex couples into leadership to do so.

To be clear, I’m not Lutheran. However, observing all of this has impacted me fairly heavily, perhaps bringing back some difficult memories of the demise of our faith community in early 2007.

One of the reasons I believe Christianity has been able to survive as long as it has revolves around its ability to adapt to cultural shifts and maintain relevancy. For example, there was a period of time when the church strictly forbade divorce, but it has largely moved away from that stance and has welcomed divorced individuals into fellowship. In fact, studies show the current divorce rate among Christians is very similar, if not identical, to the national average.

It’s hard to imagine a time when a church would split over an issue like divorce, but it did happen (part of the reason for the creation of the Anglican Church) and many people held passionate views one way or the other. I see a mirrored situation currently taking place as Christianity struggles to find a place for homosexuals in both fellowship and leadership.

The interesting thing about this decision by the ELCA is that it did not require member congregations to appoint gay elders and even allowed congregations to reject the practice internally. The fact that church splits are taking place over an issue that will probably have little pragmatic impact on them serves to show just how heated and difficult it is.

I’m not writing to weigh in on one side or the other. I am writing, however, to encourage those on both sides to try and find common ground and avoid splits if possible. Speaking from experience, the destruction of a community has a severely negative impact on those involved and should always be considered a last resort of sorts. There is lots of room for discussion and debate on the matter, but I think it is important that the issue is placed in a historical context. The church has flexed to allow for lifestyles in today’s modern day that it would have never even considered hundreds of years ago. As charged as the fight for or against allowing women into leadership was at the time, it seems rather petty in today’s modern world. The same goes with a host of other issues such as the allowance of tattoos or the orbit of the planets in the solar system.

My opinion is that none of these are worth the destruction and heartbreak that a division has both internally in the community experiencing it and externally to those looking in at the faith. If there is a way to maintain unity, I hope they can find it regardless of the perceived cost!

→ Leave a CommentCategories: Spirituality