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

This is the first of a series of posts on Sun Microsys­tem’s OpenID@Work ser­vice, which is an Open­ID Iden­tity Pro­vider avail­able for use by Sun employees.

[Update: I was asked what the pur­pose of these post­ings is — it’s simply to share our exper­i­ences in the hope that they’re help­ful to others.]

I was part of the team that put up the Open­ID Iden­tity Pro­vider. I wrote a lot of the pages, revamped Sun­’s default style sheet to work with the HTML I wanted on the pages, and took part in all the dis­cus­sions about policies and secur­ity. I’m also the “data stew­ard” for the IdP, respons­ible for ensur­ing that our policies regard­ing data pri­vacy are car­ried out. Giv­en that range of tasks in the pro­ject, it’s no sur­prise that when we div­vied up the areas for blog­ging, I picked the policy ques­tions, and oth­er people on the team will blog about oth­er areas. We’ll be cross-link­ing to each oth­ers’ posts, of course. For example, here’s Gerry­’s intro­duc­tion.

One of the good things about work­ing for Sun is that there are a lot of people with rel­ev­ant expert­ise, who also under­stand the need to be flex­ible. We spent a lot of time dis­cuss­ing the user policy with the people in the Chief Pri­vacy Office (who also let me write it in lan­guage people can under­stand), we had secur­ity experts review not only the deploy­ment but also the Open­ID spe­cific­a­tion (they’ll be blog­ging more on those aspects them­selves), and on the tech­nic­al side many people went out of their way to help. As an example, I spent most of one week­end try­ing to fig­ure out a weird MIME type prob­lem with the web serv­er with Murthy Chint­alapati (aka cvr), him email­ing “try this”, me email­ing back “nope, did­n’t work” until we even­tu­ally solved the prob­lem. In this series I’m going to be talk­ing about a few of the issues we dis­cussed, and how we resolved them. This is not to say we came up with per­fect solu­tions, or that they are neces­sar­ily applic­able to oth­er com­pan­ies or cir­cum­stances, but at the very least they will give you things to think about if you’re con­sid­er­ing a sim­il­ar project. 

We were heav­ily influ­enced by Sun­’s exper­i­ence with blog­ging, to the extent that many of our dis­cus­sions about “should we do this” were answered by “blogs.sun.com did it suc­cess­fully and here’s how”. The sim­il­ar­ity between the user policy doc­u­ments is no coin­cid­ence, for example.

If you’re look­ing for tech­nic­al doc­u­ment­a­tion on Sun­’s Open­ID sys­tem, try Hubert Le Van Gong’s infra­struc­ture descrip­tion and Open­ID @ Work — Archi­tec­ture.