Sun’s OpenID IdP: Business Purpose

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 nev­er 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 easi­er 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 Open­ID 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 form­al 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 Open­ID IdP was, and still is, to gain exper­i­ence in using Open­ID, and to make open­id iden­ti­fi­ers avail­able for Sun employ­ees on an exper­i­ment­al, opt-in basis. Sun employ­ees do not use Open­ID for any mis­sion-crit­ic­al or import­ant busi­ness applic­a­tions with­in Sun. A couple of the reas­ons for that are that this is an exper­i­ment­al ser­vice, that is not guar­an­teed to be avail­able 24/7, and with lim­ited user sup­port. Open­ID is also an untrus­ted pro­tocol. It has some well-known sus­cept­ib­il­it­ies to phish­ing and oth­er 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­son­al, not busi­ness use. The fact that it also guar­an­tees that a per­son with an authen­tic­ated openid.sun.com Open­ID is a Sun employ­ee 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­ment­al 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 remind­er, OpenSSO is open source, as is the Open­ID 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 with­in and out­side of Sun want­ing to know what Open­ID 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 Open­ID than the altern­at­ive username/password approach. On all the sites I use that are Open­ID-enabled, I need to have an account already and then can use my open­id iden­ti­fi­er 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, where­as to use my open­id iden­ti­fi­er, I have to click on the icon, fill in the open­id iden­ti­fi­er, wait until it redir­ects, sign in at the Sun Open­ID 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 open­id 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 meth­od, but that’s not reas­on enough to use my open­id iden­ti­fi­er 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 com­mer­cial-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 intern­al sys­tems, just in case they’re stolen by some rogue site. We use HTTPS for everything except the open­id iden­ti­fi­er 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 pass­word-based authen­tic­a­tion, which is more sus­cept­ible to phish­ing than some oth­er sys­tems; more about the reas­ons for that in a later post.