All 18 entries tagged Single Sign On
View all 20 entries tagged Single Sign On on Warwick Blogs | View entries tagged Single Sign On at Technorati | View all 1 images tagged Single Sign On
August 18, 2006
Protecting your online identity!
Writing about web page http://www.youtube.com/watch?v=T-Lf_v4e0Vg
This is a subject close to my heart seeing as I am involved in single sign on and password security and that like. Stephen Colbert makes a lot of sense :)
I particularly like his advice on strong passwords:
Ideally you should pick a password not even you can remember. Just close your eyes and slap the keyboard at random.
August 14, 2006
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.
July 24, 2006
Shibboleth and Question Mark Perception
Writing about web page http://www.questionmark.com/uk/perception/index.htm
I spent a fair bit of Thursday and Friday integrating (our newly upgraded to version 4) installation of Question Mark Perception with our Single Sign On system.
Perception does not support Shibboleth out of the box, but it does have a web integration layer called QMWise that allows external systems to push users and other data into the system bypassing Perception's internal authentication.
A project done at Leeds and funded by JISC has created a Java layer (QMShibb) that sits on top of QMWise and allows you to easily then protect that Java layer with Shibboleth or in fact any Single Sign On system you like.
QMShibb - Shibboleth enabling Questionmark Perception
QMShibb - Installing Tomcat with IIS 6
QMShibb - Installation, configuration and testing
With the help of a Perception consultant we got this working with our own Shibboleth based Single Sign On system sitting on top of the QMShibb java layer. So, hopefully we'll very soon be able to do a lot more with Perception as the old user management overhead has now more or less gone away.
To truely minimise the admin overhead, more work should be done with QMWise so that user groupings get pushing into Perception, but the removal of username/password issues will be a great time saver.
July 19, 2006
JISC – Access Management Showcase
Writing about web page http://www.jisc.ac.uk/index.cfm?name=event_showcase_0706
I went down to London yesterday to attend the JISC Access Management Showcase conference at the very posh One Great George Street in Westminster.
Overall I got some good little bits and pieces out of the day, but it was a bit disappointing.
The good:
- Shibboleth 2.0. Shibboleth is moving towards being a proper Single Sign On system rather than the basic federated authentication system it is now. This means proxying credentials and single logout are on the way. However, this is still some way off. Our system does this already, but it would be nice to move to the standard if it is good enough
- Levels of Assurance. LoA is a way of telling a service provider just how sure the identity provider is of a users identity. This means that if you login with a weak username and password you get LoA 1. If you login with biometrics you get LoA 4. This means that perhaps medical research data is available to you from your biometrics enabled computer at work, but only non–personal data when you login with a username/password from home
- UK Federation. A few more details on the JISC/UKERNA/BETCA sponsored UK–wide federation. This is the next step on from SDSS and will be live for early adopters in August 2006 and for everyone in November 2006. Hopefully we can get in early on this as this is the next step away from Athens. We will hopefully be going live with Athens Shibboleth for next term, but in the long term, Athens will be going away and service providers will have relationships with the UK Federation rather than Athens. The government plans is that there will be a joined up federation that not only allows sharing of resources and identities across insitutions, but right across sectors right from schools, colleges, universities, research institutes and commercial enterprises.
The bad:
- I couldn't help but feel that there was not a lot of enthusiasm at the conference. Generally the sessions finished early as there were barely ever any questions. The final panel session didn't have a single question from an audience of over 100 people! It was actually a little embarrassing. I don't know if this was an indication of it being the end of long, hot day, people just not being interested or that everyone had been so well informed that they didn't need to know any more.
On the plus side, the news coming out of this conference was definately that Shibboleth is the way of the future, so we got on the right boat nice and early here at Warwick thankfully :)
June 07, 2006
Apache with SSL and client auth on windows
I've always run any SSL I need on Tomcat on Windows as it was just really easy and less complicated and messy than getting Apache to work with SSL on Windows. Unfortunately I eventually needed to do it because of the extra power of Apache in that you can set different SSL options under different directories.
If you need to do client certificate authentication in Tomcat it is easy, but that is it, everything under that port is now protected with client auth.
In Apache you can do this:
... <Location /clientauth> SSLVerifyClient require SSLVerifyDepth 2 </Location> ...
Kindly a few people have written up some instructions on this:
Apache and SSL on Windows
Someone has also pre–built a Windows version of Apache with SSL built in:
Hunter Apache SSL builds as Apache doesn't provide it because they believe Windows is just not secure enough and allowing SSL on Windows lulls people into a false sense of security.
Anyway, most of it worked, but I just couldn't get Apache to trust my client certificates. The problem was this:
SSLEngine On SSLCertificateFile conf/ssl/my.crt SSLCertificateKeyFile conf/ssl/my.key SSLCACertificatePath conf/ssl.crt SSLCACertificateFile conf/ssl.crt/cabundle.crt
If you put certificates in the conf/ssl.crt path, when Apache starts up, it lists them all nicely saying that it has found them all, but will it trust them, will it hell. Only if you specifically put the certificate in the cabundle.crt (or whatever you've set SSLCACertificateFile to) will it work! Gah!
Anyway, working now so soon we should have a test membership of the SDSS federation so that we can do further tests on our Shibboleth SSO system.
June 01, 2006
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.
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.setType("text/plain"); description.setValue(logMessage + "<br><br>" + authFailures); entry.setDescription(description); getMessages().add(entry);
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.setLink("http://www.warwick.ac.uk/"); feed.setDescription("This feed shows warnings when users repeatedly fail to login"); feed.setEntries(getMessages()); feed.setFeedType("rss_2.0"); 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:
https://websignon.warwick.ac.uk/myadminfeed.rss?forcebasic=true
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="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0"> <channel> <title>SSO brute force warning log</title> <link>https://websignon.warwick.ac.uk/</link> <description>This feed shows warnings when users repeatedly fail to login</description> <item> <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> <dc:date>2006-05-16T16:42:58Z</dc:date> </item> </channel> </rss>
March 30, 2006
Password resets in NDS
One of the simplest aspects of increasing security of user accounts and passwords is allowing people to easily and securely change their password whenever they want.
I would not be surprised if the majority of people never changed any passwords once they have been set. In this day and age with everyone registering for so many websites, how you can keep up with regular password changes. Most people just don't see the point, they figure their password is already secure and why would anyone want to hack their account anyway?
As I've mentioned before, we don't quite have Single Sign On at the University because there are still a few places that don't tie into our central NDS LDAP directory. However, for most people that NDS password does cover a lot of things. This is good…and bad. If that password gets compromised then the attacker is going to get into a lot of things. But, if you've only got one password to remember, there would be less resistence to changing it.
At the moment you have to login to our Novell Portal (Insite) to change your password on the web (you can also change it on the managed desktop or via the service desk). However, a lot of people login via the SSO screen that secures things like SiteBuilder, Forums, Blogs, etc… If we had a change password gadget there then it would be much more visible and easy for users to change. Question is…how to do it? Our handy friends at WBS helped us out there with a chunk of code that they use.
env.put("java.naming.security.principal", user);
env.put("java.naming.security.credentials", pass);
LdapContext ldapContext = (LdapContext) getLdapCtxFactory().getInitialContext((Hashtable) env);
ModificationItem removeItem = new ModificationItem(DirContext.REMOVE_ATTRIBUTE,new BasicAttribute("userPassword",pass));
ModificationItem replaceItem = new ModificationItem(DirContext.ADD_ATTRIBUTE,new BasicAttribute("userPassword",newPassword));
ldapContext.modifyAttributes(user,new ModificationItem[] {removeItem,replaceItem});
The trick is that you have to bind as the user who is changing their password and then you must do a remove of the password attribute followed by adding the attribute back again (you can't just do a replace). This works a treat, but it only allows users to change their passwords when they already know them. It does not provide a "I've forgotten my password" facility. This is a lot harder as it means that some web app must have admin access to everyones passwords…so for now we are holding off on that one, but it is something that would be very valuable in the future as I can only imagine how many service desk calls a year we get about forgotten passwords.
Update: Having just looked at our service desk call logging system (HEAT), I see that in the last 2 weeks of term 12% of service desk calls were about forgotten passwords in some shape or form. Obviously an online password reset/forgotten password service would not get all of these, you would hope it could significantly reduce the workload of the service desk.
March 16, 2006
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.
March 09, 2006
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.