Part of a series on Sun’s OpenID@Work initiative; see the introduction for more context.
One of the interesting things about security is that you can never make anything 100% secure. You need to figure out what the risks are, how likely they are to occur, and what the damage will be if something bad does happen, and then make your plans accordingly. In most countries I’ve lived in, that means putting locks on the house doors and using them; in Canada we also have a security alarm but none of the apartments I lived in in Germany had one. Different countries, different risks (houses are often easier to break into than apartments that aren’t on the ground floor), and different plans for minimizing risks.
So it is with computer systems, and with the OpenID IdP we put up. The amount of effort that is worth putting into securing a system depends on how important the system is, and what the expected damage is if something goes wrong. So in the formal security review of the system, one of the first questions was, what’s the purpose of this system? How does that purpose balance the risks of running it? Any time you make information available via the web, there is a risk that the information will be stolen or compromised so you need to know where that might happen, what the probability is of it happening, what the expected damage is, etc.
The business purpose for the OpenID IdP was, and still is, to gain experience in using OpenID, and to make openid identifiers available for Sun employees on an experimental, opt-in basis. Sun employees do not use OpenID for any mission-critical or important business applications within Sun. A couple of the reasons for that are that this is an experimental service, that is not guaranteed to be available 24/7, and with limited user support. OpenID is also an untrusted protocol. It has some well-known susceptibilities to phishing and other attacks, only some of which can be mitigated by good programming (at least in version 1.1, the version we deployed since 2.0 isn’t finished yet). So this service that we put up was expressly made available to Sun employees for their personal, not business use. The fact that it also guarantees that a person with an authenticated openid.sun.com OpenID is a Sun employee is almost a side-effect. We thought that maybe some consumer sites (or relying parties) might offer special deals for Sun employees, or whitelist advantages, but we haven’t seen any yet. Yes, we’re on the whitelist at AOL, but I’m not sure what advantage that’s going to bring.
So, what are the results of our experiment? If you look at it in terms of what our little project group learned in terms of putting up an experimental test deployment, it was great. I got to play around with OpenSSO code and learn more about load balancing than I did previously. (As a reminder, OpenSSO is open source, as is the OpenID extension we used, so feel free to download them and try them out.) We get a lot of queries from people both within and outside of Sun wanting to know what OpenID is about, how it works, what people use it for, all of which we can answer on the basis of “well, in our deployment it looks like this”.
In terms of how many people actually use the service each week? Well, that number is pretty low. Under 35 accesses of some consumer site (relying party) per week, most weeks. I have my own theories as to why this is the case; the most obvious to me is that it’s harder to use OpenID than the alternative username/password approach. On all the sites I use that are OpenID-enabled, I need to have an account already and then can use my openid identifier as an alternative means to log in. But if I already have a username and password stored in my browser, it’s only one click to use that, whereas to use my openid identifier, I have to click on the icon, fill in the openid identifier, wait until it redirects, sign in at the Sun OpenID IdP, wait until it redirects again… it just takes a lot longer. Being the paranoid type that I am, I have added my openid information to some of these sites so that if I forget my password, or lose it when I reinstall the OS, I have a back-up login method, but that’s not reason enough to use my openid identifier regularly. In the absence of some special deal for Sun employees, or a site enabling login without registration, there just isn’t enough motivation for me to go through those extra steps.
Getting back to the risk and security issue, we did make the system secure for the things we thought really important. We are using commercial-grade software (OpenSSO is the open source variation of Access Manager) to keep people’s information secure, and users are not allowed to use the same user name or password that they use for Sun’s internal systems, just in case they’re stolen by some rogue site. We use HTTPS for everything except the openid identifier itself and the system has been tested to ensure it responds appropriately to a number of expected exploits. So users don’t have to worry about their information being compromised, as long as they don’t give it away themselves. The one weak spot is that we use password-based authentication, which is more susceptible to phishing than some other systems; more about the reasons for that in a later post.