Monthly Archives: March 2015

Integrating Spring Security With Third Party Authentication

Recently I had the opportunity to write a web application using Spring Security and a third party application for authentication. (We’ll call the third party TPS for Third Party Security. Also: TPS Reports :D)

Spring Security is a great framework, but I was confused about how to do the authentication and how best to work with it. Should I subclass the TPS User to implement UserDetails? Should I implement UserDetailsService to get said Users? How does AuthenticationManager, ProviderManager, and AuthenticationProvider play into this?

The legacy system authenticated with username and password, so that was easy to grasp. I started out with what I knew: User and UserDetails, since that was what I’d used from before with the DaoAuthenticationProvider. The problem was that I couldn’t use DaoAuthenticationProvider anymore because I didn’t have access to the password encoding and couldn’t let that default provider compare hashed passwords itself.

So I moved on to AuthenticationProvider and found a  sample and conversations around its use. This turned out to be the correct path for integrating with TPS. Here is the implementation of a @Service that implements AuthenticationProvider:

public Authentication authenticate(Authentication authentication) throws AuthenticationException {

    String username = authentication.getName();
    String password = authentication.getCredentials().toString();

    // authenticate using third party API user = TPSSecurity.getUser(username);
    if (user == null) {
        throw new UsernameNotFoundException(username + " not found");

    if (!user.isAuthenticated(password)) {
        throw new BadCredentialsException(username + " password is not authenticated");

    // once authenticated, construct successful authentication object
    // the returned auth object should have .isAuthenticated() return true, that's a common gotcha
    Collection<GrantedAuthority> authorities = ... // legacy access of this
    boolean accountNonExpired = // legacy access of this
    boolean accountNonLocked = ... // legacy access of this
    boolean credentilsNonExpired = // legacy access of this
    boolean enabled = // legacy access of this

    // this is the spring security user class
    User appUser = new User(username, password, enabled, accountNonExpired, credentialsNonExpired, accountNonLocked, authorities);
    Authentication auth = new PreAuthenticatedAuthenticationToken(appUser, password, appUser.getAuthorities());

    return auth;


public boolean supports(Class<?> type) {
    return type.equals(UsernamePasswordAuthenticationToken.class);

Note that we’re using Spring Security classes for the Authentication and UserDetails. This is actually a really nice way to isolate the dependency on TPS (by restricting it to a single class, the AuthenticationProvider), otherwise those dependencies would be spread across more classes, increasing the burden of testing and of managing Spring Profiles.

One important gotcha is that if authentication is successful, the returned Authentication object must have .isAuthenticated() return true. This is tricky because many implementations of Authentication return false by default. If that happens, your app will never authenticate anybody and you won’t know why until you look in the debugger!

Have you had to integrate with third party or legacy security systems? How difficult was it, and what were some common problems?

Leave a comment

Filed under Software Engineering

Minimal WordPress with Vagrant

Recently I blogged about finding a VirtualBox VM to use for experimenting with a WordPress installation. While it was cool to find an installation already set up, it lacked a couple things in my mind:

  1. There was a heavy initial download
  2. There was Bitnami branding on the wordpress site
  3. I didn’t have a good way to put changes to the VM under source control or undo changes

So I started looking around for Vagrant approaches to managing WordPress installations. One of the more popular is Varying Varying Vagrant Vagrants (VVV). I experimented with VVV for about a week, and it seemed like pretty solid solution. However, it still had some shortcomings for my use case… It has multiple wordpress installations and multiple databases intended for testing your plugin development across versions. This is great for plugin developers but with the flexibility comes additional complexity that I didn’t want. However, the biggest downside was: I still didn’t truly understand how it worked.

Here’s the problem: you don’t really understand something until you’ve built it from scratch. This goes for apple pies, houses, and software setups. And I really wanted to understand what all the pieces were (to a wordpress installation) and how they fit together so that I could make an installation that worked exactly the way I wanted.

So I did this: built my own minimal vagrant wordpress installation based on my older apache vagrant and mysql setups. It wasn’t hard to put together the parts I already knew and sprinkle in some PHP, apache configuration, and wordpress files. What the vagrant setup here gives you is:

  1. VM can be destroyed and rebuilt, but also changed and version-controlled (so long, bitnami!)
  2. Single-instance installation without the added configuration or complexity of multiple wordpress versions (so long, vvv!)
  3. Simple database backup and restore inside the VM of single database (I said, so long, vvv!)

I know this attitude of just doing it yourself perpetuates the “not built here” and “re-invent the wheel” syndromes so common in the software industry, but I feel like building something yourself is a great learning experience. Like making an apple pie from scratch. Maybe there’s a balance to be had between doing something yourself (for learning) and using the tools already built (to get actual work done).

The question for you, dear reader: when have you built something yourself rather than use an off the shelf solution? Why would you choose one option over another? I want to hear all about it!

Leave a comment

Filed under Software Engineering

Factors in the Peter Principle

I started following John Cook’s Blog recently, and he had a post about Successful Companies with Incompetent Employees. It made me think about places I’ve worked that incompetence ranges from “none” to “riddled with” and everything in between. And not just incompetence of engineers (where it is more easily seen if it’s there) but at all levels of management.

In years past (for me) this may have begged that the question be raised: “Are you smarter than your boss?” but with experience I think there’s more to it than that. And the comments on that post really drove it home with the personal experiences of others.

From one comment: “A lot of the Dilbert stuff is inspired by the engineers at the bottom level not having visibility into the factors driving executive decision making. Executives are by and large brilliant people. Their decisions often appear bizarre from below because they are not at liberty to fully explain them. Sometimes, business processes are responding to twisted and paradoxical incentives given by regulation. I’ve worked as an engineer at a defense contractor and there were some clearly insane things imposed on us by corporate rules, costing our organization millions of dollars a year. Digging deeper, the rules were a result of compliance with federal regulations which saved billions in taxes, enabled by different accounting enabled by compliance with byzantine laws which also begat the insane rules. Give the executives the benefit of the doubt.”

And another comment: “While I do enjoy Dilbert, it’s obviously written to flatter engineers, almost all of who would drive any company into the ground if given executive authority due to ignorance of how to actually run a business. Being a smart engineer almost always means being a stupid businessman.”

Being an Engineer does require a certain amount of smarts: the ability to ingest, synthesize, and utilize large amounts of information. But those smarts can be overrun by the limitations of perspective from years of operating at one level. The end result, when combined with engineer promotions, can result in what we would recognize as the Peter Principle. I guess my point is that while many factors can contribute to incompetence at multiple levels, lack of perspective could be a large factor in that result.

Have you seen successful companies with incompetent employees? How would you combat the deleterious effects of the Peter Principle for others and for yourself?


Leave a comment

Filed under Software Engineering