All 3 entries tagged SSO

No other Warwick Blogs use the tag SSO on entries | View entries tagged SSO at Technorati | View all 1 images tagged SSO

August 14, 2006

New web sign–on change password screen

Writing about web page

I've recently been working on a new system to allow easy, secure and informative passwords changes on the web.

At the moment if you are a main Warwick user, you can change your main ITS account password (from our NDS directory) via the managed desktop or on the web via the my.insite portal. In an effort to improve the usability and availability of password management, we decided to create a new single page that sits within the web sign–on project that would allow any user, not just central Warwick users to change their passwords.

We have a model whereby users that login to web sign–on can come from a variety of sources:

  • Central NDS directory
  • Warwick Alumni service ran externally
  • WBS Alumni service
  • WBS NDS directory
  • External user database for Warwick related users

A user does not have to worry about which of these types of user they are, they just login and the system works out where they are from and authenticates them securely at that source. Each of these sources can now optionally incorporate a password change interface that we are plugging into.

In the first instance the page will only allow central NDS users to change their passwords, but over the coming weeks we will add in as many of the other sources as we can.

Changing a password is actually a pretty boring thing really, however, we've made it a bit more interesting by giving some nice visual feedback about the strength of your password so that you can judge how strong your password is and understand why we are not letting you have a password of "letmein".

Change password screenshot

This is done through a fair bit of javascript and a bunch of AJAX calls back to the server to work out if your password is strong enough. Once all of the criteria are met, the "Change password" button is activated and it allows you to change your password.

The required password strength is probably going to be something people are going to take a little while to get used to as it is fairly strict. From the University approved new password policy:

4.1 Choice of passwords
Passwords should:

  • Be at least 8 characters long.
  • Contain at least three of the following four types of character: letters in
    lower, letters in upper case, numbers, and symbols (e.g. £$%^&*).
  • Be changed every six months for a new password (more often for
    systems requiring greater security).

In the long run we hope that this will mean that the average password strength is going to go up and this will raise people's awareness of what makes a stronger password and why it is important.

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.

April 24, 2006

What I've been up to

I've not blogged for a while because I don't really feel like I've finished anything recently.

I've been jumping between quite a few different little projects recently and all seem to not get finished.

  1. Single change password screen: I've been working on a really nice new change password screen for SSO. It will change your Novell password if you're a main ITS user or it'll change your external user password if you're of that type. What's neat about it is the AJAX password strength meters. I'll link to this when it is finally done, it's very neat though :)
  2. Importing academic data into our WebGroups project. We have a system called WebGroups that lets people create arbitrary groups for use in permissions for things like Forums, Sitebuilder and soon BlogBuilder. This import will automatically have groups for departments, modules, courses, etc… Although we already have a system that does similar, this is a much nicer system but we are just waiting on the right data right now.
  3. Various other little bits and pieces that always get in the way, bug fixes here and there. I've done a bit of work recently on SiteBuilder2 (but not much), SSO, External Users System, BlogBuilder (fixing some code that has grown really ugly).
  4. Had a bit of disaster recovery to do recently too which was a bit scary because you never know if you can get things back for real until it actually happens. Thankfully we got everything back up and running pretty quickly…phew.

So, fairly busy. The frustrating thing is not being able to concentrate on one thing. It can be quite difficult to chop and change all the time, although that is probably party my fault :)

Hopefully I'll start looking at Shibboleth for Athens again soon as it looks like JISC and co. are getting themselves sorted out and the momentum seems to be building around the academic community for this again.

November 2018

Mo Tu We Th Fr Sa Su
Oct |  Today  |
         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      


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