NHibernate.AspNet.Identity | ASP.NET Identity Provider for NHibernate | Identity Management library

There are a couple ways around this, including a child class that implements a public whose setter applies the value to the protected id field.

However these are bandaids. Generally these problems are encountered because of a difference in how people view models. Either it is a reusable Data Transfer Object or it is not.

In the world where it is not, you have to shoehorn business objects into bindable models and always run into these weird problems.

In the world where they are, they are custom tailored to fit the data needs and are mapped into business objects with something like an automapper. More importantly, by making a model to fit this request, you protect against attacks on accidentally exposed parameters.

If the makeshift business object has public properties that change your behavior, they can be exploited by sending additional parameters back with the post request.

I know this does not specifically answer your question, but following the path where models are not DTO's is probably not the right answer either.