Category: Identity and Privacy

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.

Sun’s OpenID IdP: Introduction

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.

Privacy and Identity

One of the bet­ter pieces on iden­tity and pri­vacy that I’ve read recently, and well worth every­one read­ing, wheth­er you do any­thing much with iden­tity man­age­ment or not, is from Dav­id Wein­ber­ger. Iden­tity man­age­ment in an unequal world dis­cusses how when sign­ing up for things is easi­er, people can take advant­age of that to ask us to sign up more often, to give more inform­a­tion than we really need to. I’ve been well trained at Sun to ask now why any­one needs the inform­a­tion they’re ask­ing for. Can­’t they do with less inform­a­tion? What are they going to do with it? These are the basic ques­tions every­one needs to ask every time some web site or shop asks for per­son­al inform­a­tion of any sort, basic­ally why do they want it and why do I need to give it? If more people ask the reas­on why, maybe few­er com­pan­ies will be need­lessly intrusive.

Naming Names

Phil Karlton said (at least once in my hear­ing any­way) that nam­ing things was one of the two hard tasks in com­puter sci­ence (read­ing X Toolkit Intrins­ics — C Lan­guage Inter­face, to which he con­trib­uted, will give you some idea why he said it); I dis­covered the truth of this yet again when writ­ing the FAQ for our Iden­tity Pro­vider for Open­ID. In this case, it was even more con­vo­luted, being about what to name the thing that names names.

When a Sun employ­ee signs up at the Sun IdP there is no neces­sity for them to put their real names in the fields marked “first name” and “sur­name”; they can use a fic­ti­tious name if they choose (or put noth­ing at all). In com­mon Eng­lish, this fic­ti­tious name is often called a pseud­onym. The vari­ous dictionary.com defin­i­tions of pseud­onym would seem to fit this usage very well, so I was pre­par­ing to use it in the FAQ. Except for, it turns out that those steeped in iden­tity man­age­ment ter­min­o­logy tend to find that plain-Eng­lish usage of the word confusing. 

In SAML, for example, a pseud­onym is defined as A pri­vacy-pre­serving name iden­ti­fi­er assigned by a pro­vider to identi­fy a prin­cip­al to a giv­en rely­ing party for an exten­ded peri­od of time that spans mul­tiple ses­sions; can be used to rep­res­ent an iden­tity fed­er­a­tion. In Liberty Alli­ance work, the defin­i­tion is An arbit­rary iden­ti­fi­er assigned by the iden­tity or ser­vice pro­vider to identi­fy a Prin­cip­al to a giv­en rely­ing party so that the name has mean­ing only in the con­text of the rela­tion­ship between the parties. The same or sim­il­ar mean­ing is used with­in WS-Secur­ity (the user iden­tity [is] provided in a SAML asser­tion as a pseud­onym) and WS-Fed­er­a­tion (A pseud­onym ser­vice allows a prin­cip­al to have dif­fer­ent ali­ases at dif­fer­ent resources/services or in dif­fer­ent realms, and to option­ally have the pseud­onym change per-ser­vice or per-login).

So in order to make life easi­er for those poor, eas­ily con­fused iden­tity man­age­ment experts, I’ll be using the term “fic­ti­tious name” in the FAQ, where I would oth­er­wise have used “pseud­onym”, an added cost of one let­ter and one word per usage. I hope they appre­ci­ate my efforts to help them.

Sun and OpenID

I’ve been heads-down on a pro­ject which was just announced (though not yet up and run­ning, so I’m still work­ing hard with the rest of the team on final details) about Sun put­ting up an Open­ID IdP (iden­tity pro­vider). The idea is that this IdP will veri­fy that the per­son using an Open­ID of the form http://openid.sun.com/username is a Sun employ­ee. Everything else is self-asser­ted, so people can use pseud­onyms and non-Sun email addresses, but they will be a Sun employ­ee. It’ll be inter­est­ing to see what hap­pens and how we can use it, once it’s live. That info will be pos­ted to developers.sun.com/identity as soon as the IdP is up and running.

I’ll be post­ing some tech­nic­al details of what I’ve been doing, and some tips and tricks to help someone else take the OpenSSO code and cus­tom­ize it; oth­ers on the team will be blog­ging about their pieces. 

It’s been a fun pro­ject and it will be even more fun see­ing what people do with it. We’re using the tag sun­open­id, or you can fol­low along on Plan­et Iden­tity.

Privacy in the Internet Age

Dar­ren Bare­foot has some inter­est­ing thoughts about pri­vacy in the inter­net age and the way in which today’s north amer­ic­an teen­agers are grow­ing up post­ing everything about their lives on the inter­net. Up till now, most of the dis­cus­sion I’ve read on the sub­ject has revolved around the effects on future careers of post­ing poten­tially embar­rass­ing stuff on the web. Derek Miller points out that bosses will also have embar­rass­ing stuff up on the web, although there will still be a gen­er­a­tion gap there for some years until those future bosses become bosses (assum­ing that most bosses will still con­tin­ue to be older than many of the people they employ).

We’re start­ing to dis­cern the out­lines of some likely effects of this now. For example, if I get an inter­est­ing email from someone I haven’t heard of, I’ll look them up in Google or Yahoo search, or Linked­In. I don’t neces­sar­ily ignore the email if I don’t find any inform­a­tion about the per­son, but I can see that hap­pen­ing in the future — if you don’t exist in search engines, is that going to be con­sidered weird?

Find­ing people I’ve lost touch with is get­ting easi­er every year, as long as they haven’t changed their name. I’ve man­aged to track down old friends, and oth­ers (who did change their name after mar­riage) have man­aged to track me down. Mind you, I’m rel­at­ively easy to find. 

One effect I’m won­der­ing about is on politi­cians: cur­rently politi­cians either have to be squeaky clean, or good at hid­ing things the elect­or­ate might not like to hear about. Rudy Giuliani’s per­son­al life includes three mar­riages and gay friends, all well-doc­u­mented; in pre­vi­ous years this would have made a pres­id­en­tial cam­paign basic­ally impossible. Now it just makes it more dif­fi­cult, or maybe it’s just dis­cussed more; in future years when more inform­a­tion is avail­able about every­one on the inter­net, and hid­ing these things is going to be impossible, will voters be more accepting?

One inter­est­ing aspect to this is how little inform­a­tion is avail­able about Google’s founders — and more than a little iron­ic, giv­en how easy they’ve made it to find inform­a­tion about oth­er people. An art­icle on Moth­er Jones, via Bruce Schnei­er, has more.