This evening I started playing around with RPX, the OpenID consolidator from JanRain. I hit a few hurdles along the way, and I thought I would share a little of those experiences with others trying out RPX.
My first step was to download the RXPLib from Google Code, which is a full API wrapper for RPX. It gives you all the method calls you’ll need to work with the RPX API. It is built using the .NET 3.5 Framework, but it worked fine with my 2.0 web application.
The example code provided by RPXNow.com in C# isn’t particularly helpful. It is basically a Windows Console application, which allows you to basically interact with the API. N.B. It requires that you pass parameters to the application, so if you struggle to figure that out, view the project properties and edit the “Command Line Arguments” before you start to run the application in debug mode.
Step right past the console app, and login to RPXNow.com, with any OpenID enabled account and create a website profile. Then use the template created for you, and plug that code straight into your login page of your new website project. Create a call back page to which the authorisation token will be returned to. Add this URL to the script in the place holder (e.g. http://localhost:3456/ReceiveToken.aspx).
Running the web application you’ll get a simple “Sign In” link, which when clicked offers a number of OpenID providers to select. You need to select one, which will redirect you to that provider. Agreeing to the conditions of your provider, you login and are passed back to your token receiving page.
Here is where you implement your tie in to your Membership Provider. It makes a lot of sense to implement a custom Membership Provider, and hook the user into that.
The key areas you want to consider when a user logs into your application using OpenID is:
- The user won’t be using a password to login
- Does the email address provided by the OpenID provider already exist in your database?
- Does the preferred user name passed back also exist?
Because the OpenID user doesn’t need a password to login (although you can offer them one), the CreateUser method of your Membership provider will need to have a default password created for them. Ideally you create a random one and email it to them in their welcome email. This does two things. It allows them to continue logging in with their preferred OpenID, or if they want to, log in with their user name and password.
If the email address already exists in your database (and ideally email addresses would be unique in your provider), you are able to use the “Mapping” feature of RPX. Mappings lost me to start with, because they are not very well explained on the RPX Now website. Quite simply, it allows you to tie up your existing user, to an identity on RPX. After authentication in your Token page, you can call the RPX service to map your local UserId (CustomerId, AccountId, etc) to an identity in RPX. In this way, you can map one of your user accounts to multiple RPX identities.
If the preferred user name returned by RPX already exists in your database, you’ll obviously have to offer the user an alternative user name (unless you use email addresses as user names).
In summary, RPX looks great, and is very simple to implement in a basic format. I’m sure I’ve only just scratched the surface in the few hours I’ve played around with it.
Notably, the basic version of RPX is free, but offers a limited subset of features compared to the premium accounts. One of the issues with the basic version is that your users won’t log in to your website directly, but be transferred to https://youraccount.rpxnow.com. As a result, users may be put off as they are warned constantly about phishing these days, and this looks like a blatant phishing attempt.
Secondly, implementing RPX means that you are putting all of your eggs into one basket. That’s not to say that RPX is going to disappear, but it could.
However, saying all of that, I think RPX is a great idea. Having a single simple control that offers users a great selection of OpenID providers in a easy to understand format is what OpenID needs at the moment.
I look forward to getting something more concrete together soon.