Saturday, January 17, 2009

Why using RPXNow is a bad idea

Janrain has been a great influence in the OpenID community and I thank them for all their efforts.  They are, nevertheless, a company that must generate profits, and their recent invention of RPXNow is one attempt at doing that.  It generates revenue for them: check.  But is it really in your web site’s best interest to use RPXNow instead of using OpenID directly?  I don’t think so.

I have not used RPXNow myself, for reasons I will describe.  So what I will discuss is from my reading the documentation about their service and seeing how it works from an end user’s point of view. 

Confusing to users

When users login, their OpenID Provider will usually tell them that they’re logging into instead of  Even if your visitors are willing to go ahead and login in spite of this oddity, you are teaching your users to get phished by disregarding what ought to be a warning message to them.

RPXNow allows you to customize this “realm” URL that is displayed, but doing so requires more work on your part, and costs more per month for the service.  And RPXNow was all about making it easy, so doing the extra work to get the right realm displayed to your users is something of a step backward for their primary selling point, I’d say.

Less stability introduces an intermediary between your site and the OpenID Provider.  One of the criticisms of OpenID already is that your users won’t be able to log into your site if their Provider is down or cancels their account.  Adding RPXNow between your web site and the Provider adds yet another possible point of failure for your users.  It is worse, in fact, because users may have multiple Providers so they can still log in if one goes down; but if you use RPXNow and RPXNow goes down, they are helpless and you won’t see any logins at all. 

OpenID has also been criticized because logins can take a bit longer due to the 1-2 hops between your server and the OpenID Provider to complete authentication.  This may be a moot point, but it can only get worse when you add yet another third party in the authentication protocol.

Less security flexibility

Your site may need to make its own decisions about which Providers it is willing to accept OpenID logins from.  Or it may need to control the policies that should apply when dealing with those Providers.  Since RPXNow completes these steps for you, you lose out in your ability to customize the process to the same extent you could if you were using OpenID directly at your site.

Proprietary protocol

OpenID was designed exactly to allow your sites to accept logins from many other OpenID Providers.  Doing this right and securely is in fact a big job, but there are numerous free and open source libraries that have done this heavy-lifting for you and you just need to hook up to it. 

RPXNow’s sales pitch is that they handle the complexities of the OpenID protocol for you.  But to get that you have to talk to them in their proprietary protocol.  They give you a library for that so that it’s “easy”, but what have you gained from this?  Without RPXNow, you need an OpenID library and to hook it up to your site.  With RPXNow, you need their RPXNow library and to hook it up to your site.  The frontends to either library that you will have to interface with turns out to be very similar.  So it’s not significantly easier to hook up RPXNow than it is OpenID itself (assuming you picked a decent OpenID library). 

There is one advantage to RPXNow abstracting OpenID away from you that I can think of however.  It is their job to stay on top of patching their implementation of the OpenID protocol and keeping you secure instead of yours.  For a big company, that actually is more of a risk than a benefit.  But for many web sites, this is an advantage because otherwise they may get OpenID ‘working’ and then consider it done, and ignore all the security updates and new OpenID versions that may come out that may put their users at risk.

Vendor lock-in

Janrain claims to make it easy for you to stop using their RPXNow service if your needs change.  But they do not volunteer the complications that may be involved in parting ways. 

Remember how the realm is often ‘’?  Much worse than simply confusing users, it can end up locking users out of their accounts.  Google, and others to follow, choose to use a feature of OpenID that allows them to protect their users from collaborating relying parties so that their usage on the Internet cannot be tied together.  But the way this is done is using that same realm URL.  If your realm URL ever changes, all your users who log in using their Google OpenIDs will have to create new accounts with your site and will no longer be able to log into their old ones!  This would be very upsetting to your customers, and you would get emails/calls in about this from every one of your loyal Google customers.

Let’s say you start with and decide to switch to the more costly option of sticking with RPXNow but using your own domain name for the realm, or just switching off of RPXNow altogether.  Either way, you’re screwing over your Google customers (and potentially other OpenID Providers that choose to follow Google’s example).  The only way to use RPXNow without this eventual end result is to pay the money to RPXNow to use just your own domain name at the start.  But again, that’s more work and more money.  And if you just accept OpenID yourself directly you can avoid the more money, and avoid the other issues we’ve discussed at the same time.

Alternatives to the benefits they offer

RPXNow does make logging in easier for your users than the typical OpenID text box.  With some work on your end, you can achieve a similarly easy UI for your users on your own.  Or better, the OpenID libraries that you can use directly can have this functionality built-in so that it’s still just as easy, and yet you’re hosting it all yourself.

RPXNow also offers user login and account creation statistics.  But this too can be achieved relatively easily using other means like Google Analytics, which is a free service.


Since RPXNow introduces several problems, web developers should avoid it for now in favor of an OpenID library.  Janrain would do well to repackage RPXNow as a product that can be purchased instead of a service in order to avoid most/all of the issues I list above.

Thursday, January 08, 2009

Remotely enable RDP

Have you ever been away from your work PC, tried to Remote Desktop (RDP/mstsc) into it, only to realize that you’ve forgotten to enable RDP before you left work?  Ever shake your head at the irony that if you could only remote in, you could enable RDP?

Well now you can:

Method 1

The simplest way is to run a free tool:

Method 2

If you’d prefer to not run an unknown tool and give it admin access to your remote machine, you can do it by hand:

  1. Fire up regedit.exe on your local machine.
  2. File -> Connect Network Registry -> your remote machine name for which you have admin access.
  3. File -> Import… -> and import the following file:

    Windows Registry Editor Version 5.00



    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]


  4. Reboot your remote machine:
    shutdown \\yourremotemachine /f /r /t 0
Method 3

If you can use WMI you can use the Win32_TerminalServiceSetting class in the root\cimv2\TerminalServices namespace. The SetAllowTSConnections method will allow you to enable the ts connections. You will need to set both the AllowTSConnections and the ModifyFirewallException params to 1.

I’m not sure how to use WMI myself.  If someone know how to please comment.