All entries for May 2006

May 17, 2006

HTTPS Basic Auth RSS feeds for system monitoring

Most applications log messages out to a log file somewhere on a server but they are a pain to look at. You could setup log4j to append messages via email, but to me it seems unreliable. Also, you have to decide who is going to get these emails and they can be quite invasive if you don't always need to read them all.

RSS has been a great step forward in opting into information on the web rather than emails. So, why not do the same for system messages.

My particular use case involves some data from our Web Sign On system and these messages are quite sensitive so it is no good just publishing a public RSS feed.

My solution looks something like this:

1) I have a listener class within SSO that monitors activity and logs it in the usual way.
2) I have another listener that receives messages from the logging listener that looks for unusual activity, such as repeated login failures or lots of requests for the same IP address. When it finds something unusual, it puts an entry into the feed that will be displayed to the admin user. This is done with the Rome Atom/RSS java utilities project. This is a great open source project that allows you to easily create/read feeds in all different formats.

SyndEntry entry;
SyndContent description;
entry = new SyndEntryImpl();
entry.setTitle("Warning for user " + user);
entry.setPublishedDate(new Date());
entry.setUri("" + entry.getPublishedDate().getTime());
description = new SyndContentImpl();
description.setValue(logMessage + "<br><br>" + authFailures);



These SyndEntry's are generic enough to be turned into any kind of feed, be it Atom, RSS 2.0 or RSS 1.0.

3) I then have a controller that pulls all of those messages and puts them in a feed for that admin user view view:

SyndFeed feed = new SyndFeedImpl();

feed.setTitle("SSO brute force warning log");
feed.setDescription("This feed shows warnings when users repeatedly fail to login");


response.setContentType("application/xml; charset=UTF-8");
SyndFeedOutput output = new SyndFeedOutput();
output.output(feed, response.getWriter());

4) This page is protected by our SSOClientFilter. This will allow HTTP Basic Auth, but only over SSL. As I don't trust Bloglines or anyone with my username and password, I just need to put the address into Thunderbird or a similar RSS reader like this:
The "forcebasic=true" on the end tells the SSOClientFilter to use Basic Auth rather than redirecting to our SSO login screen as it would usually if it was requested by me in the browser. When Thunderbird tries to read the feed, it is prompted for authentication and so prompts me the user in Thunderbird for my username and password and sends those securely to the feed.

5) Hey presto, we have an authenticated RSS system log:

  <?xml version="1.0" encoding="UTF-8" ?> 
 <rss xmlns:taxo=""
xmlns:dc="" version="2.0">
  <title>SSO brute force warning log</title> 
  <description>This feed shows warnings when users repeatedly fail to login</description> 
  <title>Warning for user cusyac</title> 
  <description>The last 3 login attempts for user cusyac were failures. Check wsos_auth.log
Tue May 16 17:37:47 BST 2006|Auth failed|cusyac|Username/password not found|137.205.x.x<br>
 Tue May 16 17:36:38 BST 2006|Auth failed|cusyac|Username/password not found|137.205.x.x<br>
Tue May 16 17:34:37 BST 2006|Auth failed|cusyac|Username/password not found|137.205.x.x<br></description> 
  <pubDate>Tue, 16 May 2006 16:42:58 GMT</pubDate> 
  <guid isPermaLink="false">1147797778580</guid> 

May 16, 2006

Factories are not meant to be this beautiful

Writing about web page

Follow the link above to see some amazing pictures from "Transparent Factory in Dresden" which is the VW factory that makes Phaetons.

And pick up your car from the car tower:


May 14, 2006

Audi A4 1.9 TDi (100) Sport for sale

Audi A4 2003 (03) AUDI A4 1.9 TDI 100 Sport 4dr Diesel Saloon
27,000 miles
PAS,Drivers airbag, Passenger airbag, Side airbags, ABS, Remote central locking. 17" alloys.
Perfect condition, one owner. Full Audi Service History. 11 months tax and MOT.
Price: £12,495

This is pretty much the suggested price from Parkers and it is in great condition.

If you're interested, contact me or comment here.

So, I'm selling my Audi, but I've had it for 3 years and even though I'll miss it, it is time to move on :)
As standard I've put the car in Auto Trader , but I thought as a little experiment I would put it on here too. If I sell it through this page, then great, but I kind of want to see how high up in Google I get and how many people land on this page.

Update: Decided to keep it in the end, just isn't worth getting rid of considering how much I've invested in it over the last 3 years...may as well enjoy it now that I've paid for the depreciation

May 09, 2006

OSCache and SSO

I am responsible for the Web Sign On system at Warwick. Between development and lives services, we have 80 registered services (quite a few duplicates because Blogs for instance is registered on my machine, a test server and the live server) that are allowed to talk to SSO.

SSO is responsible for authenticating users to the web apps and finding and sending attributes about users to those applications. The most heavily hit part of the system is the web service that allows an application to get the details for a usercode. It looks something like this:


The response is a simple bit of plain text with name/value pairs such as name, email, department, etc… This system has been kept simple for legacy reasons and does not use the complex transport that our Shibboleth/SAML based new SSO uses.

Last time I checked the stats, we had about 40,000 checks for users a day. Each application then caches these requests internally within our Userlookup API. This system has worked quite well for a long time, but recently we have had some reliability problems with NDS so if an application needs to get the names/emails for 100 users for some user listings and those users are not in the applications local cache, they then have 100 web requests to make which are suddenly taking a second or two each when they usually take 200ms each.

Even if SSO is running at full speed, requesting a lot of users at 200ms a time can still add up. With this in mind, we've now added a server side cache at the SSO end of things. OSCache to the rescue. Having never used this before, I wasn't sure how easy it would be, but it was simplicity itself: (approximate code)

try {
_results = (Map) _userByIdCache.getFromCache(getUser(), CACHE_TIMEOUT_SECS);
} catch (NeedsRefreshException nre) {
_results = _userByIdProcessor.getResults();
_userByIdCache.putInCache(getUser(), _results, new String[] { "all"});

I put a wrapper around the existing controller that published the results of the lookup that simply tries to get the results from the cache, if they are not there or have expired, it populates the cache. Simple. A bit of Spring config wires it all in, including a really simple binding of the Cache into the JMX console so I can easily monitor and clear the cache.

The outcome is that we now have a cache that gets quicky populated for the benefit of all client applications because if application A requests user USERA and it takes 200ms, when application B also requests user USERA, it now takes 5ms rather than the previous 200ms.

May 2006

Mo Tu We Th Fr Sa Su
Apr |  Today  | Jun
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31            


Search this blog

Most recent comments

  • One thing that was glossed over is that if you use Spring, there is a filter you can put in your XML… by Mathew Mannion on this entry
  • You are my hero. by Mathew Mannion on this entry
  • And may all your chickens come home to roost – in a nice fluffy organic, non–supermarket farmed kind… by Julie Moreton on this entry
  • Good luck I hope that you enjoy the new job! by on this entry
  • Good luck Kieran. :) by on this entry


Not signed in
Sign in

Powered by BlogBuilder