All 12 entries tagged ITS

Files project update

Follow-up to Spring and Hypersonic/Hibernate tests from Kieran's blog

It’s been a while since my last update on this project. Unfortuately we’ve not done as much as I would have liked. Both Sarah and I have had holiday and we’ve been busy on other projects.

We’re back in the swing of things now and we’re moving forward a lot quicker now that most of the underlying infrastructure is in place.

To give an idea of the size of the project already (as well as just numbers can tell you anything):

• 75 classes and interfaces
• 22 test classes with 50 tests
• 15 hibernate mapping files
• 5 database tables (we are mapping quite a few classes to a single table in quite a few places)
• 14 jsps (not many as we’ve not got loads of interfaces to some of the underlying code yet)

So, what does this code do then?

We’ve recently added quotas and the ability to email a file to someone. This basically sends an email with a link in it to a unique download URL that lasts a week and lets the person who sent the file keep track of downloads of that file (they get notified by email when it downloads and can see the download count on an web interface within their account).

We’ve also got the permissions system in now so that you can give view/edit/admin permissions to a person or a group of people (as usual there is no interface for this yet…just the code).

Everything is still pretty ugly as we’ve not done any graphic design work, so I’m not going to post any screenshots!

: 24 Nov 2006 12:23 |  Tags: Files ITS Java Programming Work |  Comments (0) |  Close comments |  Report a problem

Spring and Hypersonic/Hibernate tests

Follow-up to Files project dev server from Kieran's blog

Having been away on holiday for 2 weeks and having quite a bit of catching up to do with other stuff, we’ve not made huge leaps in the last few weeks. However, we’re building up steam again now and have finally sorted out after a few restarts the domain model we’re going to be going for around the key aspects of accounts, files, folders, etc…

Up until now for speed of prototyping, we’ve been working with Spring, but not yet involved a database as we can quite easily just talk directly to the file system for now. However, now is the time to start getting more complex and we need somewhere to store all the metadata of all kinds about the files and accounts.

As usual, we’ll try and incrementally do the Hibernate mappings and start to build the database scheme. To do this quickly we’ll be building against some tests and a hypersonic database to start with. Spring provides the handy “AbstractTransactionalDataSourceSpringContextTests” class which allow easy binding of Spring objects and also a simple way to plug in transactional capabilities to your tests.

By coupling these test with the Hypersonic database which can be built and torn down in memory in just milliseconds, we can prototype the database very quickly.

Hibernate session-factory config

<session-factory>
        <property name="dialect">org.hibernate.dialect.HSQLDialect</property>
         <property name="use_outer_join">true</property>
        <property name="hbm2ddl.auto">create-drop</property>

        <mapping resource="......hbm.xml"/>
   </session-factory>

Spring sessionfactory and datasource

<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
        <property name="configLocation"><value>hypersonic-hibernate.cfg.xml</value></property>
        <property name="dataSource" ref="dataSource"/>
    </bean>

    <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName">
          <value>org.hsqldb.jdbcDriver</value>
        </property>
        <property name="url">
          <value>jdbc:hsqldb:.</value>
         </property>
        <property name="username">
          <value>sa</value>
        </property>
        <property name="password">
          <value></value>
        </property>
    </bean>

So based on your mappings files, the database schema gets created in a new hypersonic database for each test giving you a working and clear schema to test against. Magic.

public class HypersonicTests extends AbstractTransactionalDataSourceSpringContextTests {

    protected String[] getConfigLocations() {
        return new String[] { "file:apps/webinterface/src/applicationContext.xml","file:apps/webinterface/test-src/hypersonic-db-context.xml"};
    }

}

public class DbConnectionTests extends HypersonicTests {

    private SessionFactory _sessionFactory;

    public final void testDbConnection() throws Exception {

        Session session = getSessionFactory().openSession();

        session.save(new AccountImpl(null, null, "Test", null));

        session.flush();

        List accounts = session.createCriteria(Account.class).list();

        assertEquals(1, accounts.size());

    }

    public SessionFactory getSessionFactory() {
        return _sessionFactory;
    }

    public void setSessionFactory(final SessionFactory sessionFactory) {
        _sessionFactory = sessionFactory;
    }

}

: 01 Nov 2006 10:25 |  Tags: Files ITS Java Programming Work |  Comments (0) |  Close comments |  Report a problem

Files project dev server

Follow-up to Getting a project up and running from Kieran's blog

One of the important things to try and get ready as early as possible is a test/pre-production system that is fairly close to what you expect your live environment to be. This is so that you don’t spend the whole time developing on a single JBoss instance on a single processor Windows box with local storage and then deploy on a multi-processor, multi-JBoss and remote storage box and discover that nothing works!

We are now starting to run Solaris 10 which gives us the great Zones feature. Our sys admins have setup a zone on one of our new boxes that is a test/pre-prod environment for the files project. We’ll run something like this:

• Single Apache 1.3x instance with HAProxy to load balance between the JBoss instances
• Two JBoss instances both running live rather than a live and a standby
• For now local storage, but eventually we’ll use our NetApp

The twin live JBoss instances means that our application will have to be completely stateless. This is a good thing for scalability, but it makes multi-step processes within the application a bit harder as we won’t have a session to store data in. This is usually not a problem for simple applications, but working on something like a mutli-step zip upload could be tricky.

The other advantage of having a test instance up and running is that you can start to point very early test users at it (rather than a local instance on your own machine). This gets you some good early feedback/ideas/bug-spotting.

: 05 Oct 2006 14:51 |  Tags: Files ITS Java Programming Work |  Comments (0) |  Close comments |  Report a problem

Getting a project up and running

Follow-up to New online files project from Kieran's blog

Starting a new project is quite intimidating as you start with absolutely nothing. Before you really get going you’ve got to get the following stuff together:

1. A JIRA project (this is our great bug tracking software from Atlassian)
2. A CVS project (gotta backup that code)
3. A basic project structure in Eclipse (need to ensure you can easily build multiple distributions from a single code base)
4. An Ant build.xml file to build the project…even though there’s not really got much to build yet…there will soon
5. All the basic Jar files you’re going to need, such as Spring and the like

Once you’ve got the basic project infrastructure in place, you might actually be able to write some code. Some people might say that you’ll have to write a spec first, but that’s not how we do things. We are very keen to get things out the door because we and our users don’t really know what they want until they start using stuff. This works well for us as we’re pretty good at being responsive to our users’ needs and can keep the project nice and easy to refactor and change as we go along.

Being a good boy, I’m making sure that I’ve got lots of tests right from the start. This kind of project is basically all about files so the key thing that it would be nice to get right first time is how to model the file system. It is worth spending a bit of time on the really key parts of the system as you could refactor this later on, but you really wouldn’t want to.

Whilst this very early coding and infrastructure work is going on, it is quite hard to have more than one person working on the project. Once there is a bit more meat to the project someone else can start to get a bit more involved and start something like the file download part of the project. In the mean time it’s worth doing some things that can be done in parallel. A couple of things we have going on in the background are:

1. The visual/graphic design work is starting to be looked at by Hannah
2. Looking into how we might implement certain file system protocols is being done by Sarah

Although it’s only a couple of days in, I already have some reasonably good code for basic file management and file upload, but not much in the way of a web interface for it yet, except a basic file upload and file listings page.

: 25 Sep 2006 11:45 |  Tags: Files ITS Java Programming Work |  Comments (0) |  Close comments |  Report a problem

New online files project

After working on Single Sign On and BlogBuilder and various other smaller projects on and off over the last couple of years, I have a big new project to get my teeth into.

Basically we (me and Sarah) are reworking how members of the University can get at their files over the web and send and receive large files given the restrictions and problems with emailing large files.

The full scope of the project is not yet known so I couldn’t just list all of the features that the system will have. However, our basic goals are:

• Upload files to a web based file store (and of course then download them so that you can get at them at home easily)
• Set permisisons on those files (based around our SSO and WebGroups system)
• Be able to send other users files that you’ve uploaded so that they get a link to the file to download over the web
• Allow non-Warwick users to send you large files that you won’t be able to get over email

There is a lot more possible detail in these features that we’ve had a think about already, but a lot of the finer decisions are yet to be taken.

We like to do things in a fairly agile way so that we get out working software quite quickly and then rapidly improve it based on testing and user feedback. This means hopefully there’ll be something to see relatively quickly (but don’t expect miracles) and it’ll improve with new versions all the time.

I’ll be writing about our progress here and giving some insights into how projects like this get built here at E-Lab.

: 20 Sep 2006 14:22 |  Tags: Files ITS Java Programming Work |  Comments (3) |  Close comments |  Report a problem

New web sign–on change password screen

Writing about web page https://websignon.warwick.ac.uk/origin/changepassword.htm

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".

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.

: 14 Aug 2006 08:58 |  Tags: ITS Java Programming Single Sign On SSO Work |  Comments (6) |  Close comments |  Report a problem

Web groups and SSO integration for our web apps

I've recently been working on improving our Web Groups system. This is a central system that allows users to create their own arbitrary groups of Single Sign On users. These groups are then exposed through some web services which allow our other web apps to use them as the basis of permissions or grouping in whatever way they see fit.

Along with SSO, Web Groups is one of the systems that really helps us build very powerful systems with very easy and fine grained permissions…without having to actually do much work in each of those applications.

Web Groups now includes all sorts of groupings now such as:

• Students in a department
• Teaching staff in a department
• Students going a particular course
• A full or part time students in a department
• Students in a particular year of a course
• Tutor groups

All of this data is automatically pulled in from our Academic Data Store (ADS) project. This means that the data is always up to date. Previously if someone wanted to protect say a SiteBuilder page so that only people doing that module can see it, they had to find and keep up to date a list of the ITS usercodes of all students on that module. Now they just need to enter a group name and it'll be kept up to date for them.

If our groups are not good enough, people can make their own groups. So for instance you could create a group that is all the students on a module plus the 3 staff involved with that module. Again, this will all stay up to date as the students on that course change, even at the start of a new year.

We currently have a similar system in BlogBuilder, but we'll be moving over to this new system soon as it is more reliable, powerful and just plain faster.

By using these shared services such as SSO and Web Groups, we can build much more integrated and powerful solutions that we just probably couldn't get from an external vendor.

: 01 Jun 2006 15:03 |  Tags: ITS Java Programming Single Sign On |  Comments (0) |  Close comments |  Report a problem

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.

: 24 Apr 2006 12:30 |  Tags: BlogBuilder ITS SiteBuilder SSO Webgroups |  Comments (2) |  Close comments |  Report a problem

Alliance & Leicester online banking

Follow-up to Is one password enough with Single Sign On? from Kieran's blog

Interestingly, just after writing about different levels of security, my bank has gone and changed their online banking system.

Alliance & Leicester online banking demos

They have put in two new measures.

1) The first measure is to be a bit more sure that you are who you say you are when logging in. The first time you register, the take a look at what they call "Your computer characteristics" (basically probably your IP address and browser agent). They then use this to let you in with just a customer number and PIN from known computers, but ask you something else like your mother maiden name or place of birth as another security question before letting you in.

2) The second measure is to let the customer know for sure what site they are logging into. This is for people who fall for the fake bank emails they get. Basically, the first time you register you are shown a random, but distinctive image and are asked to enter a phrase as well. These are then show to you after you enter your customer id but before you enter your PIN. The idea being that if you login and don't recognise your own image and passphrase, then don't enter your final PIN as you might be on a fake site. To be honest I'm not sure how much this is going to help as the kind of people who fall for these fake emails and sites are probably also fooled by something like just saying. "Your previous image has no expired, please pick a new image and pass phrase." Oh well.

: 16 Mar 2006 20:39 |  Tags: ITS Single Sign On |  Comments (2) |  Close comments |  Report a problem

Is one password enough with Single Sign On?

When you login to your managed desktop machine, SiteBuilder, Warwick Blogs or any number of university systems, chances are that you will are using a single username and password. And that's great most of the time.

Using Warwick's Novel Directory Server (NDS) as the master source for people's usernames and passwords means that we can authenticate to lots of stuff from this single secure source. Not everything uses this one username and password as your GroupWise/SMail/Unix logins can have different passwords.

Single password vs Multiple passwords.
Pros:

• Only one password to remember, making you more likely to make it complex and hard to guess
• Having just one password for everything makes it less hassle to change a bad/compromised/old password without having to worry about which systems this particular password is for
• One central system for logging authentication activity, making it easier to spot and challenge suspicious activity

Cons:

• That one super secure password gets stolen and everything is open for abuse, not just one or two systems
• All it takes is one place where you need to login insecurely and all your secure logins are vulnerable

We have recently started moving every online login from lots of individual screens within each web application to a system whereby everyone just gets redirected off to a centralised login screen. We can then concentrate on making this one place more secure rather than worrying about all the little places where people try to do authentication.

Along the theme of the problem of losing that one secure password is the idea of temporary credentials or varying levels of security depending on the activity trying to be performed or the behaviour of the user who is trying to login.

For a number of years companies have been using token generators to authenticate people. These are basically hardware devices that generate a one-off key that can prove your identity. Unfortunately these are expensive and could easily be lost or stolen.

Another method that some banks are talking about using (I'm not sure if they already have got these methods deployed) variable security. Let's say you were logging into Warwick Blogs first thing in the morning and were doing it from your residences room. SSO might check your IP against your login history and if you enter your username and password at your usual typing speed/style then it'll let you straight in. However, if you later in the day went to view a page in SiteBuilder, you'd still be logged in and all would be fine. However, if you then went to change your student records in some way, we might decide to request stronger authentication. At this stage you'd get prompted for your password again and also an extra PIN or perhaps the name of your first school.

This solution means you still just have one password, but also have some additional data that you'd get asked for when doing sensitive activities or if you were logging in from say a different country…or rather a hacker was trying to login as you from another country.

In the context of Warwick Blogs you might want to subscribe to an RSS feed. Unfortunately we do not provide a local RSS reading application that respects permissions. So if your RSS feed contains a few restricted entries, you'd not see them in a public RSS feed that got read by somewhere like bloglines. You could use HTTP Basic Auth over SSL to authenticate with your username and password to get that feed. However, that would mean leaving your one and only password in some untrusted external application. It might be nice in this case if we could generate you a temporary password that you could use that would only work for this service and would in no way compromise your main password.

Anyway…this is all just random off the top of my head stuff. It may well be that these features are overkill, but as more and more is done over the web at Warwick we need to make sure we know who's doing it.

: 09 Mar 2006 17:14 |  Tags: ITS Single Sign On |  Comments (3) |  Close comments |  Report a problem