If you’re not interested in CAS, Grails, Spring Security, and passing custom attributes then I advise you to stop reading now!

Our situation was different from Daniel’s because we aren’t using LDAP, but we still have a need to “piggy back” some custom attributes on the CAS 2.0 ticket validation response. It’s actually less involved than what Daniel had to do. Here’s the gist of it, quick and dirty.

Configuring the CAS to pass custom attributes

I’m assuming you are already doing your customizations via the “overlay” approach with Maven, so I will assume that’s already up and running. You’ll need to overlay (at a minimum, I think) 3 files:

1. src/main/webapp/WEB-INF/view/jsp/protocol/2.0/casServiceValidationSuccess.jsp
2. src/main/webapp/WEB-INF/cas.properties
3. src/main/webapp/WEB-INF/deployerConfigContext.xml

First of all, in your CAS overlay source tree, overlay the file src/main/webapp/WEB-INF/view/jsp/protocol/2.0/casServiceValidationSuccess.jsp and add the following content as a child element of <cas:authenticationSuccess/>:

<c:if test="${fn:length(assertion.chainedAuthentications) > 0}"> <cas:attributes> <c:forEach var="auth" items="${assertion.chainedAuthentications}"> <c:forEach var="attr" items="${auth.principal.attributes}" > <cas:${fn:escapeXml(attr.key)}>${fn:escapeXml(attr.value)}</cas:${fn:escapeXml(attr.key)}> </c:forEach> </c:forEach> </cas:attributes> </c:if>

The attributes themselves are provided by a bean in deployerConfigContext.xml called “attributeRepository”. It defaults to some kind of stub with a hard-coded map of attributes. You don’t need to change these for now, but later of course you will want to implement your own “attributeRepository” to fetch the real attributes from your database/LDAP/whatever.

The final step on the CAS side requires that you log into the Services Management section of CAS. To do this, you’ll need to:

1. Make sure to configure cas.properties with your correct HTTPS server URL.
2. Add yourself as a valid user with ROLE_ADMIN in the userDetailsService section of deployerConfigContext.xml.
3. Restart the CAS and open your browser to https://localhost/cas/services/ or whatever is the equivalent URL for your CAS installation.
4. Once logged in, go to the “Attributes” section and shift-click to select all the attributes. Click “Save Changes”.
5. Verify that the multi-select shows all these attributes are still selected.

Making a Grails app work with CAS

Create a Grails project. We used Grails 2.0 but any of the recent 1.3.x versions should also be fine.

Install the Grails plugins “spring-security-core” and “spring-security-cas”. Take your normal steps to configure Spring Security for Grails; I won’t go into that here. Then, add something like the following to the bottom of Config.groovy:

grails.plugins.springsecurity.cas.active = true
grails.plugins.springsecurity.cas.serverUrlPrefix = 'https://localhost:8443/cas'
grails.plugins.springsecurity.cas.loginUri = "/login"
grails.plugins.springsecurity.cas.serviceUrl = "http://localhost:7000/cas-spike/j_spring_cas_security_check"
grails.plugins.springsecurity.cas.key = "balderdash"
grails.plugins.springsecurity.cas.proxyCallbackUrl = "http://localhost:7000/cas-spike/secure/receptor"
grails.plugins.springsecurity.cas.proxyReceptorUrl = "http://localhost:7000/cas-spike/secure/receptor"

Of course you’ll want to use real ports and URLs as befits your environment.

Also in Config.groovy, turn up the debugs so you can see traffic from the CAS! This was extremely valuable in debugging why attributes weren’t coming across earlier.

log4j = {
    ...
    debug   'grails.plugins.springsecurity'
    debug   'org.codehaus.groovy.grails.plugins.springsecurity'
    debug   'org.springframework.security'
    debug   'org.jasig.cas.client'
}

Create a test controller that’s protected, to force a login through CAS. I made mine grails-app/controllers/FooController.groovy:

import grails.plugins.springsecurity.Secured
import grails.plugins.springsecurity.SpringSecurityService

@Secured(["IS_AUTHENTICATED_FULLY"])
class FooController {
    SpringSecurityService springSecurityService

    def index() {
        render "Howdy"
    }
}

Bounce your Grails app so the configs take effect. Then try to hit your new controller. With any luck, you should see it redirect to CAS, where you will have to sign in. If your sign-in is successful you’ll see “Howdy” in your web browser. Great success!

Consuming the custom attributes in your Grails app

Don’t get too excited just yet! You might be totally stoked to see CAS working, but you aren’t yet accessing the custom attributes are you?

Let me step back for a moment and say that half the battle (at least) was getting the custom attributes to be passed in the first place. This seems to be a dark area of the CAS 2.0 protocol. As far as I could gather, the custom attributes that we so painstakingly enabled in the earlier sections are not really part of the CAS specification at all! Fortunately it seems to be a common enough hack that both Spring Security and PHP support it (and maybe Rails and others…?).

Look in your Grails logs for a debug message that looks something like this:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationSuccess>
        <cas:user>andy</cas:user>
        <cas:proxyGrantingTicket>PGTIOU-1-Erm9JGxwDD7YJ1GCsqa0-cas</cas:proxyGrantingTicket>
        <cas:attributes>
            <cas:uid>uid</cas:uid>
            <cas:eduPersonAffiliation>eduPersonAffiliation</cas:eduPersonAffiliation> 
            <cas:groupMembership>groupMembership</cas:groupMembership>
          </cas:attributes>
    </cas:authenticationSuccess>
</cas:serviceResponse>

Got it? Good, that means the CAS is configured correctly and passing some custom attributes. If not, don’t proceed, go back and figure out what went wrong.

The only thing we have to do now is make Spring Security look for the CAS attributes returned by the client, and map them to your “principal” once logged in. This is where Daniel Bower’s plugin source was super helpful. Our approach (closely based on Daniel’s plugin) was to implement a class in src/groovy/CasUserDetailsService.groovy with the following contents:

class CasUserDetailsService extends AbstractCasAssertionUserDetailsService {
    private static final List NO_ROLES = [new GrantedAuthorityImpl(SpringSecurityUtils.NO_ROLE)]

    // Custom attribute names that should be mapped over into Spring Security roles
    private static final String[] authorityAttribNamesFromCas = ["cas_authority"]

    private GrantedAuthorityFromAssertionAttributesUserDetailsService grantedAuthoritiesService = new GrantedAuthorityFromAssertionAttributesUserDetailsService(authorityAttribNamesFromCas)

    @Override
    protected UserDetails loadUserDetails(Assertion casAssert) {
        casAssert.principal.attributes.each { key, value ->
            log.info("CUSTOM ATTRIBUTE FROM CAS: ${key} = ${value}")
            // TODO - do something intelligent with the attributes
        }

        def casUsername = casAssert.getPrincipal().getName()
        def localUser = User.findByUsername(casUsername)

        //Create the user profile if it does not already exist
        if (!localUser) {
            localUser = new User(username: casUsername)
        }

        // Load the authorities from CAS
        def casUser = grantedAuthoritiesService.loadUserDetails(casAssert)
        def casAuthorities = casUser.authorities ?: NO_ROLES

        return new GrailsUser(casUser.username, "no_password", true, true, true, true, casAuthorities, localUser.id)
    }
}

Wire in this bean in Grails by making your grails-app/conf/spring/resources.groovy something like this:

// Place your Spring DSL code here
beans = {
    authenticationUserDetailsService(CasUserDetailsService)
}

Restart the app and try again to login through CAS. You should now see the custom attributes printed in the Grails log.

Next steps

Now that you’re getting attributes, you’ll want to do two things:

1. Store and pass useful attributes from your CAS. For us, this is stuff like firstName, lastName, email, etc. as well as role/permissions stuff.
2. Do something useful with the attributes in your client app(s). For us, this is mostly centered on synchronizing data with the authoritative CAS data.

Wow, what a long and boring blog post this was. But I sure wish I had it a week ago, it would have saved me a lot of time and frustration. If you find it useful, drop me a note in the comments below to restore my sense of purpose and accomplishment!

But there’s another important advantage that I have noticed lately: everything is written in plain old Java code.

There’s no applicationContext.xml. No Hibernate. No Maven. No large suite of unit and integration tests that must be run to make sure stuff is “wired up” correctly. In fact, there’s almost no XML at all (the app itself does utilize XML for storing user data, but that’s a data store, not a project artifact).

When I make a code change in my IDE, it immediately informs me if I’ve broken something. Compile time checking FTW! And when I want to run the app, you know how long it takes? Less than one second. That’s right folks, I click the launch button and in one second Loadster is up and running. It doesn’t have to fire up a bunch of containers, parse XML, build a dependency tree or any of that. It doesn’t have to generate meta-class wrappers with CGLib or anything. The code just runs.

Modern Web Frameworks

Compare that to the web frameworks you’ve probably been using. As far as I can reckon, it all went off the rails (no pun intended) with the advent of Struts and Spring and the like. They threw away compile-time checking at the application level, and replaced it with loose XML wiring. No doubt it seemed like a great idea at the time (mock objects? reusability? loose coupling?). But what did we give up? Compile time checking. Now almost everything becomes a runtime error. You have to actually run the app — walk the minefield — in order to find out what you broke.

Software teams responded to this problem by creating lots of automated unit and integration tests. Now, how do you know if you’ve mis-wired something? You run a big suite of tests and wait for the outcome! Then you hope your test coverage is good enough that you didn’t miss something. Unit tests aren’t a bad thing, but they should be used sparingly, for testing critical units of code.

The next generation of web/MVC frameworks (probably starting with Rails) took it a step further. They responded to the bloated, out of control XML artifacts by pushing “convention over configuration”. I’m a Grails fan, and I see how this is a huge improvement. As long as the conventions are consistent, it works really nicely.

But these next-gen frameworks also switched from static to dynamic languages (Ruby, Groovy, etc). Dynamic languages are really great for writing “glue” code. They’re generally a good fit for web apps. But as soon as I have to write serious back-end application logic, I feel the pain. Again, I miss the compile time checking. The encapsulation. The static typing. I don’t want to have to write and run a series of unit tests, only to find that I’m improperly treating a string as a number somewhere deep in the bowels of the application. These are all things the compiler (and IDE) used to do for us!

Everything’s a trade-off I guess. The newer web frameworks really aren’t bad. But if you want a breath of fresh air, try writing a static Java app again. You might be surprised how quick and easy it is.

There are 3 main services for cloud-based load testing that I am aware of: LoadStorm, LoadImpact, and BrowserMob.

1. LoadStorm

The self-titled “lowest cost cloud load testing tool”. Very competitively priced and straightforward to get started. Within a couple minutes, I was signed up on the free plan which allows load tests of up to 25 virtual users for up to 30 minutes.

The UI is easy enough to navigate but no frills. There are a few places where I had to stop and think about what a particular control meant. There is help text off to the side which could be expanded and collapsed, and I never got lost.

Before you can configure tests against a particular server, you have to verify it by placing a file in the root directory or adding a verification tag to the index page. Since this is a load testing tool, this seems pretty crucial to prevent abuse (DoS attacks). The verification process was easy and about what I’d expect. Surprisingly, LoadStorm was the only one of the three that required site verification.

Unlike some of the client-side load testing tools, LoadStorm doesn’t have a way to record steps. You have to add steps manually, each step being either “Open a page”, “Click a link”, or “Submit a form”. While I missed the recording, the tool at least does a good job of parsing out links and forms to facilitate these last two options.

I had one hiccup with submitting the login form into my app. It seemed like the session/login cookie wasn’t being persisted, so the subsequent step had a login failure. Eventually this resolved itself though, not sure if it was something I did.

One other thing that seemed odd: “wait times” aka “think times” are done at the test plan level as a min/max, rather than between steps. It enforces a minimum wait time of 10 seconds between pages. In the real world, it’s not uncommon at all for users to linger less than 10 seconds on a page before clicking to the next one, so this minimum seemed a bit unrealistic to me.

Once you have created a test plan (scenario), running the test is easy. While the test is running you only get 2 live graphs, each with a couple series. They basically amount to throughput (kb/s and requests/s), response time (average and peak), and error rates.

Unfortunately there’s no further diagnostics or ability to tell what type of errors are happening, or see a breakdown of statistics for a particular step/page only during test runtime. As a result I felt a little bit out of touch with how the test was progressing.

After the test is finished, a few more reporting options do become available, along with CSV export.

Pros: Low price, easy to get started.

Cons: Limited reporting during and after a test, lacks recording so scripting is a bit labor intensive.

2. LoadImpact

Nice, pretty site and app. Easy to register.

Their pricing model is based on “credits” rather than a subscription. As far as I can tell, 1 credit lets you run 10 simulated browser users, or 40 virtual users, for up to 1 hour. LoadImpact’s simulated browser users don’t actually seem to use Selenium or any real web browser; they just have multi-threading that allows ~4 resources at a time to be downloaded, somewhat like a real browser. Their virtual users, on the other hand, are single-threaded.

They have nice charts and graphs throughout the application. When configuring a test, they let you choose one from about 5 “load zones” (data centers from which the traffic will be generated).

They actually DO let you record browser steps using a proxy server, by manually configuring your browser. Unfortunately, when I tried it nothing was recorded in either Chrome or Firefox (it proxied my browser’s requests, but nothing showed up in the script). Since recording didn’t work for me, I had to edit the script by hand.

Editing the script by hand can be done in either a text or graphical editor. The text editor requires that you type the script in Lua. The graphical one is not really as graphical as we would have hoped; it is in fact just like Lua but with little icons instead of curly braces and stuff like that. Lua syntax is really easy, so I ended up just coding the script manually.

Once you finally figure it out, their scripts are fairly powerful, definitely more so than LoadStorm. Upon starting a test, it tells you how many credits it will cost ahead of time. My 10 minute, 10 user test cost me 1 credit, or roughly $2.10, so still quite cheap. A 60 minute, 100 user test would cost 15 credits, or $45.

The runtime dashboard has a lot more stuff than LoadStorm. It has a really swell Google map showing the location of their data centers, and your server, and where the traffic is coming from. The runtime dashboard uses HighCharts which are pretty nice, and you can add more graphs for certain metrics on the fly.

Once a test is finished, you have a URL to the test report, which is exactly the same dashboard that was shown at runtime. I was hoping for a bit more in-depth reporting after the test is run, but since the runtime dashboard was fairly powerful, I was not too disappointed.

Pros: Pretty UI, powerful scripting once you get the hang of it, nice dashboard and reporting.

Cons: Recording didn’t work for me, and the graphical script editor didn’t really offer any advantage. I ended up hand-coding my script in Lua.

3. BrowserMob

BrowserMob’s claim to fame is that they use Selenium scripts and real web browsers to generate the load, which allows for more realistic results, some AJAX support, and better error reporting. They also offer “virtual users” (VUs) which in their parlance is a single-threaded, single-connection HTTP client. They cost 1/10 of what you pay for “real browser users” (RBUs).

Overall, BrowserMob’s pricing strikes me as a lot higher than its competitors, with the basic plan starting at $499 a week for up to 100 RBUs or 500 VUs. There is a free plan for smaller load tests, though, with no weekly price but you have to buy “cloud dollars” once your 10 trial dollars run out.

They have a nice, modern website and registration process, with good marketing.

For script recording, they give you two choices. You can create a basic script that just loads one or more URLs in a browser, with no programming required. Or you can upload a Selenium script that you record yourself using Selenium. Not a bad approach really. Unfortunately if you upload a Selenium script, you can only use RBUs, not VUs. To use it for VUs, you have to use their converter which simplifies it into GET and POST, and loses any validation logic you might have put in there.

On to running a test. First thing, I tried to do a small test with 50% RBU and 50% VU, but it wouldn’t let me, saying all the users in a test must be of the same type. Bummer. Oh well, I went with the RBU one because that’s more interesting. Like the other cloud-based services, there is a few minutes wait before the test can start, while they get things fired up.

The runtime dashboard doesn’t have as many features as LoadImpact did, but the features they do have make sense. At least you can see total throughput, failures, and response time by “step” (Step 1, Step 2, …). I wish it were easier to see what URL each step consisted of, instead of having to cross reference it back to the script. The other thing that’s unfortunate is that the dashboard stats only show one-minute increments, so it doesn’t feel very “alive”. It’s definitely adequate though.

I was expecting some really nice reports after the test finished, but unfortunately they were the same as the dashboard. Given the high price and the degree of polish elsewhere in the app, I was hoping for some nice reports to make sense of your test data. No dice. But if you’re determined enough, they do let you download a MySQL dump with your raw test data!

Pros: Great marketing and website, Selenium scripts with real browsers are powerful.

Cons: Pricey, runtime dashboard is nothing special, and reporting is pretty bare bones.

Conclusion

Assuming you are looking for a cloud-based load testing tool, all three of these services have their appeal. If you really care about using Selenium scripts, then BrowserMob is your only choice. For the most full-featured reporting, go with LoadImpact. If cost is a big deal to you, LoadStorm may be the safest bet. Personally I think I would be drawn most to LoadImpact, if their recording had worked properly.

The biggest change I noticed is (no surprise here) a big push to The Cloud. Unless you’ve been living under a rock, of course, you’ve noticed that everybody and their former roommate is making their apps run on the cloud.

There are some fairly compelling reasons for this. Treating hardware, bandwidth, and processing power in general as a commodity has some huge advantages for any company that wants to focus on core competencies. And there are economies of scale to be had by paying a big cloud provider such as Amazon or Microsoft to handle everything, and pay only for what you use.

As far as load testing is concerned, the cloud is appealing because it represents a cheap way to scale up simulated users as high as you want. One of the big barriers to entry of load testing (besides the shockingly high cost of licensing the software itself) is infrastructure. If you’re going to simulate 10,000 or so users hitting your production-like test servers, you need a decent amount of hardware and network throughput at your disposal to do so. Solutions like LoadStorm and BrowserMob seem to be gathering a lot of steam in this area.

There are a couple notable disadvantages to cloud-based load testing services, though:

• They tend to be weaker on the scripting/recording features than the client-side tools. Sure, HTTP load testing just boils down to a bunch of GET and POST requests anyway, but for testing complex transactional systems it’s helpful to record realistic user flows, rather than just sending the same few requests over and over. If you are actually meticulous enough to hand-code each GET and POST request for a cloud-based tool, then more power to you.
• The cloud can only generate traffic on sites that are publicly accessible. This is great for load testing your new WordPress blog or whatever, but most companies that are making serious web apps develop and test them in-house. It’s not realistic to put your new application in production before running load tests, and having a shadow production environment for this purpose (while ideal) can sometimes get expensive.

I was reminded of this when I came across this post on performance tuning of SQL queries by Sam Saffron at Stack Overflow.

Sam talks in a lot of detail about the tools, queries, and specific optimizations he used to achieve a 10x improvement in baseline performance for some of their pages. That was useful, but not as interesting to me as his general methodology.

First of all, they were logging each query’s execution time through their own database connection class. So from the very beginning it was really easy to see how much of the page’s total load time was spent in database queries vs all the other factors (processing data, rendering, network latency, etc). Turns out in their case, as with many applications, the database access was the biggest chunk.

Once he realized this, he didn’t immediately start tweaking SQL. He looked at a month’s worth of production logs to see the impact in aggregate. Since this was one page in the system, it made sense to see the total impact over a period of time, to avoid wasting his time on a single page if there are bigger fish to fry.

Turns out over the course of 1 month, that slow page really did have a signifiant impact on site averages. So he proceeded to tune it. As an added bonus, some of the improvements he made had positive ripples through the rest of the application.

So, a couple little morals of the story:

1. Measure everything! Track performance for all the key layers of your application, as well as total response times.
2. Do a little cost-benefit analysis in your head before diving down rabbit holes. Before tweaking things, first determine where your time is best spent. Attack the worst bottlenecks first.

Of course, baseline performance is one thing but performance often changes unpredictably under heavy load. Most bottlenecks are non-linear. Something might do just fine for a while, and suddenly become exponentially slower once a certain load threshold is reached.

For our fancy new graphical script editor (coming soon) I was doing a custom drop shadow effect. Here’s what it boiled down to:

public static void fillRoundRectangleDropShadow(GC gc, Rectangle bounds, int xOffset, int yOffset, int radius) {
	gc.setAdvanced(true);
	gc.setAntialias(SWT.ON);
	gc.setBackground(Display.getCurrent().getSystemColor(SWT.COLOR_BLACK));
	gc.setAlpha(0x8f / radius);

	for (int i = 0; i < radius; i++) {
		Rectangle shadowBounds = new Rectangle(bounds.x + xOffset, bounds.y + yOffset, bounds.width - i, bounds.height - i);

		gc.fillRoundRectangle(shadowBounds.x, shadowBounds.y, shadowBounds.width, shadowBounds.height, radius, radius);
	}

	gc.setAlpha(0xff);
}

We could certainly get a lot fancier with the options; I use an arbitrary 0x8f for the shadow alpha because that looks good where we are using it. But you could parameterize that as "intensity" or something.

In this case, we had a domain class called “Task” with a Map collection called “attributes”. The idea is to be able to shove rather unstructured metadata into that map, without polluting the domain class itself with a lot of extra fields that are seldom used.

Today I had to query for all tasks with a certain key in their “attributes” map, and was pleasantly surprised at how easy it is:

return Task.findAll(
    "from Task t where t.attributes['resident'] = :c",
    [c: resident.id]
)

No doubt you could do the same with the Criteria API. Another win for Grails/Hibernate!

But the next few months are going to be really exciting — a new visual approach to test scripting, really big load engines, monitors, and a couple other surprises. All these will be in the Loadster 1.x branch, so customers who purchase 1.1 will get the future updates for free.

Now comes the big publicity game: targeted ads, social media, blah blah blah. Not as fun as actually building software, but a necessary evil.