Anyway

Part of a series on Sun’s OpenID@Work ini­ti­at­ive; see the intro­duc­tion for more context.

One of the inter­est­ing things about secur­ity is that you can never make any­thing 100% secure. You need to fig­ure out what the risks are, how likely they are to occur, and what the dam­age will be if some­thing bad does hap­pen, and then make your plans accord­ingly. In most coun­tries I’ve lived in, that means put­ting locks on the house doors and using them; in Canada we also have a secur­ity alarm but none of the apart­ments I lived in in Ger­many had one. Dif­fer­ent coun­tries, dif­fer­ent risks (houses are often easier to break into than apart­ments that aren’t on the ground floor), and dif­fer­ent plans for min­im­iz­ing risks.

So it is with com­puter sys­tems, and with the OpenID IdP we put up. The amount of effort that is worth put­ting into secur­ing a sys­tem depends on how import­ant the sys­tem is, and what the expec­ted dam­age is if some­thing goes wrong. So in the formal secur­ity review of the sys­tem, one of the first ques­tions was, what’s the pur­pose of this sys­tem? How does that pur­pose bal­ance the risks of run­ning it? Any time you make inform­a­tion avail­able via the web, there is a risk that the inform­a­tion will be stolen or com­prom­ised so you need to know where that might hap­pen, what the prob­ab­il­ity is of it hap­pen­ing, what the expec­ted dam­age is, etc.

The busi­ness pur­pose for the OpenID IdP was, and still is, to gain exper­i­ence in using OpenID, and to make openid iden­ti­fi­ers avail­able for Sun employ­ees on an exper­i­mental, opt-in basis. Sun employ­ees do not use OpenID for any mission-critical or import­ant busi­ness applic­a­tions within Sun. A couple of the reas­ons for that are that this is an exper­i­mental ser­vice, that is not guar­an­teed to be avail­able 24/7, and with lim­ited user sup­port. OpenID is also an untrus­ted pro­tocol. It has some well-known sus­cept­ib­il­it­ies to phish­ing and other attacks, only some of which can be mit­ig­ated by good pro­gram­ming (at least in ver­sion 1.1, the ver­sion we deployed since 2.0 isn’t fin­ished yet). So this ser­vice that we put up was expressly made avail­able to Sun employ­ees for their per­sonal, not busi­ness use. The fact that it also guar­an­tees that a per­son with an authen­tic­ated openid.sun.com OpenID is a Sun employee is almost a side-effect. We thought that maybe some con­sumer sites (or rely­ing parties) might offer spe­cial deals for Sun employ­ees, or whitel­ist advant­ages, but we haven’t seen any yet. Yes, we’re on the whitel­ist at AOL, but I’m not sure what advant­age that’s going to bring.

So, what are the res­ults of our exper­i­ment? If you look at it in terms of what our little pro­ject group learned in terms of put­ting up an exper­i­mental test deploy­ment, it was great. I got to play around with OpenSSO code and learn more about load bal­an­cing than I did pre­vi­ously. (As a reminder, OpenSSO is open source, as is the OpenID exten­sion we used, so feel free to down­load them and try them out.) We get a lot of quer­ies from people both within and out­side of Sun want­ing 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 deploy­ment it looks like this”.

In terms of how many people actu­ally use the ser­vice each week? Well, that num­ber is pretty low. Under 35 accesses of some con­sumer site (rely­ing party) per week, most weeks. I have my own the­or­ies as to why this is the case; the most obvi­ous to me is that it’s harder to use OpenID than the altern­at­ive 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 iden­ti­fier as an altern­at­ive means to log in. But if I already have a user­name and pass­word stored in my browser, it’s only one click to use that, whereas to use my openid iden­ti­fier, I have to click on the icon, fill in the openid iden­ti­fier, wait until it redir­ects, sign in at the Sun OpenID IdP, wait until it redir­ects again… it just takes a lot longer. Being the para­noid type that I am, I have added my openid inform­a­tion to some of these sites so that if I for­get my pass­word, or lose it when I rein­stall the OS, I have a back-up login method, but that’s not reason enough to use my openid iden­ti­fier reg­u­larly. In the absence of some spe­cial deal for Sun employ­ees, or a site enabling login without regis­tra­tion, there just isn’t enough motiv­a­tion for me to go through those extra steps.

Get­ting back to the risk and secur­ity issue, we did make the sys­tem secure for the things we thought really import­ant. We are using commercial-grade soft­ware (OpenSSO is the open source vari­ation of Access Man­ager) to keep people’s inform­a­tion secure, and users are not allowed to use the same user name or pass­word that they use for Sun’s internal sys­tems, just in case they’re stolen by some rogue site. We use HTTPS for everything except the openid iden­ti­fier itself and the sys­tem has been tested to ensure it responds appro­pri­ately to a num­ber of expec­ted exploits. So users don’t have to worry about their inform­a­tion being com­prom­ised, as long as they don’t give it away them­selves. The one weak spot is that we use password-based authen­tic­a­tion, which is more sus­cept­ible to phish­ing than some other sys­tems; more about the reas­ons for that in a later post.