Transferring info in a ViewModel between Views and Controllers in an ASP.NET MVC 2 site without allowing modification of info

Question

I'm building an ASP.NET MVC 2 site where I'm currently implementing an OpenID sign-up form. Unfortunately, I'm foreseeing a possible security bug/vulnerability inside my architecture.

Here's how I want OpenID login to work:

1. User requests /Account/Login, Controller sends back OpenIDLogin View.
2. User enters their OpenID into the View, then OpenID authorization takes place, and finally the OpenID is returned to the Controller.
3. The Controller checks whether the OpenID is currently in use by a user in the system or not. If it is, the user is logged in to that account. If not, the registration process begins.

And now, the OpenID registration process:

1. The OpenID identifier, as well as any other information provided by the OpenID provider (such as email address or name), is put into my custom ViewModel and sent to my OpenIDRegistrationForm View.
2. The RegistrationForm View stores the OpenID in a hidden field to make sure that it gets sent back to the Controller.
3. The user fills in the RegistrationForm View and sends it back to the Controller.
4. The Controller creates the user account and puts the OpenID into the database.

The bug that I see within my architecture is that a user could modify the hidden value in the RegistrationForm View. Thus, they could spoof their OpenID!

I will make sure to add another round of checking to the final Registration Controller Action to make sure that the OpenID that is provided doesn't exist yet, but there is still a possibility for spoofing.

Can my architecture be improved somehow? I don't want this to end badly...

One solution I'm considering is encrypting the OpenID before I send it to the View and then decrypting it when it reaches the Controller. Should I try this?

Thanks for your help in advance.

Answer 1

hmm.... okay. the "right" solution is, provide an IDP like http://startersts.codeplex.com/

and that one stores for the anonymous user the OpenId token, until he is fully authenticated.

the simple solution is, give him a sort of sessionid, and store it on the server side.

an even simplier solution is just, encrypt the openid, so the user cannot change it.