Paul E. Jones' Blog

For most sizable corporations, there is a desire to be able to federate identity for users within the corporation to third-parties. For example, your company might provide travel services to employees through a third-party portal, allow employees to view paychecks on a third-party web site, etc. To allow this to be done safely and securely, the two businesses must work together to come up with a way in order to authenticate the corporate user. All too often, though, the third-party has absolutely no hand in the authentication step and merely trusts that a URL from the company, that somehow identifies the user, is legitimate.

Some of the inter-domain federation mechanisms are really, really insecure. I’ve seen some that are so bad that all one needs to do is grab the URL and use it to access an employee’s confidential information.

OpenID can be used to address this issue securely and without using proprietary mechanisms. Rather than authenticating the user and redirecting the user to a third-party with some kind of trust “credentials” inside the URL, the company can just redirect the user to the third-party and provide the user’s OpenID identifier. For example, when redirecting the user to the corporate travel site, perhaps this might be the URL used:

http://travelsite.example.com/?openid=http%3A%2F%2Fopenid.packetizer.com%2Fpaulej

The receiving travel site will receive the OpenID identifier http://openid.packetizer.com/paulej and can then go through the normal OpenID procedures to authenticate the user with the corporation’s OpenID server. This is far better than passing “credentials” around via URLs. Equally important, the method is very simple and secure. Further, it removes the need to create and manage a host of proprietary mechanisms between various “trusted” third-parties.

For years, I’ve been frustrated with the fact that I have so many login identities and passwords for literally hundreds of web sites. Of course, I’m certainly not alone in that respect, as just about everybody has way more logins than they can deal with. The problem has been so bad that I laugh when I read a notice on a web site that says to make your password secure, using mixed-case and special characters. Say, something like this: rS3YC%e@6. Oh, and don’t write it down, is the advice given. Memorize it. And don’t use the same password on two sites. Yeah, right. Nobody can do that. Perhaps a person can manage to do that with one or a very few passwords, but not hundreds of passwords.

That is why I am so delighted to see OpenID taking off. For those who do not know, OpenID solves this problem by giving users a single user identity and password that they can use to access all of their OpenID-enabled web sites. Right now, sites like Blogger, Facebook, Flickr, MySpace, WordPress, Google, Yahoo!, and many more sites have support for OpenID. We even have OpenID support for Packetizer Forums, so you don’t have to keep up with a separate ID to discuss stuff about VoIP, videoconferencing, or cloud computing.

One of the really cool features of OpenID that is not fully appreciated is the fact that it is possible for you to log in once and never have to log in again. You can roam around from site to site and be automatically logged in. Perhaps you might have to provide your user ID, but you don’t have to provide your password if your identity provider supports the right features in OpenID. With the OpenID software we use on Packetizer, you can indicate when you log in the first time whether you want to be prompted for a password again or not.

Anyway, I’m excited since more and more web sites are adding support for OpenID. This makes using the Internet so much more enjoyable.

Recently, President Obama signed into a law a bill that would help encourage tourism to the US. Called the Travel Promotion Act, every visitor to the United States will be required to pay an entry fee.

That certainly does not sound like it would encourage tourism to the US. “Welcome to the US. Now, pay your fee.”

There is, of course, more to the bill than that. The bill is intended to create a marketing organization and a set of programs to help encourage visitors to come to the United States. This is all fine, but why do people not want to come to the United States, anyway?

Well, there are reasons. First, many visitors to the US must get a visa. There are certain countries where this is not required, but even in those cases, visitors are required to go online and complete some entry form, otherwise they will be denied entry.

All visitors are required to fill out far more paperwork than any other country in the world (the white I-94 or green I-94W form), staple crap into their passports, and are required to ensure that the departure document is properly returned before departure. Failure to do that might jeopardize the visitor’s ability to come to the US again, and will certainly increase the likelihood of having to get a visa the next time the visitor might wish to come to the US.

Upon arrival, US immigration officers will take the visitor’s mug shot and fingerprints, almost as if the person arriving is assumed to be a felon. Sure, all of this was done to “protect national security” after the attacks of 9/11, but does the leadership of the United States not understand how this makes a visitor feel?

Oh, and have you ever watched how our border agents (especially those running the scanners) treat visitors when they do not follow instructions? They are absolutely rude. It does not matter that the visitor cannot speak English. They don’t care. They’ll just yell at the visitor as if they’re a common criminal. I’ve seen it happen far too many times.

So, because we put up so many barriers to people who want to visit the United States, people do not come. And then we wonder why. So, we create a marketing organization and fund it to encourage visitors.

Do the folks in Washington not understand the root problem? I can hop on a plane and fly to Switzerland tomorrow. I’ll be greeted with a smile, not required to fill out any documents at all, and given no harassment whatsoever by the border agents. There is a difference and people feel it.

Lots of folks I work with in the ITU-T, which is a part of the United Nations, have explicitly asked me to not hold meetings inside the United States for all of these reasons — and so I don’t. Perhaps one day our government will stop treating visitors so poorly.

Web-based interfaces (also called APIs) are growing in popularity. Some are very trivial, such as an interface that returns a list of stock quotes, while others are more complex. There are a number of technologies in use today, but what I’ve been focused on primarily is REST.

REST is a very simple idea, but there are so many opportunities for making it complex. One example is REST Versioning. We posted some recommendations on how to deal with REST versioning and we also have some discussion of XML versioning to support that.

Some people love them and some people hate them, but HTTP cookies are really darn useful. Cookies are the way web sites remember who you, avoiding the need to enter and re-enter your password from day to day. Cookies can also store information, such as user preferences on a given computer.

Facebook, blogs, and many other public web sites use cookies. They can be misused, of course, such as by advertisers who track your movement around the Internet. However, most uses of cookies are not so invasive. But, there is a big problem with cookies: they’re entirely insecure.

Cookies might be encrypted by the server, so certain information in the cookie might be secure. However, when cookies are used to maintain a user’s logged in state, the user is at risk of having his or her session stolen. This happened recently with Facebook, in fact. However, what if a hacker is able to grab a user’s session and post malicious content or delete photos or do other destructive acts in the name of the user? This is scary.

What solutions exist? Presently, the only solution is to use HTTPS. HTTPS will encrypt all traffic to and from the client. Unfortunately, HTTPS comes with a high price: encrypting and decrypting every single bit of data between the browser and server is expensive.

So, a colleague and I thought about a better approach and we came up with a proposal for just encrypting a part of the cookie information passed between the client and server. Have a look and tell me what you think. The draft can be found here.