We have an application which uses SQL Server as the back end. It was client server based, now it will be web based. Our implementation to logon was a user ID and password hash/salt stored in the database. Additionally, all policies and roles were stored in our table schema and assigned to users and or user defined groups. So, they would login, authenticate, and then we would pull the role(s) and policies for that user so they could use the parts of the application that thier role(s) and policies allowed for.

We are investigating WIF now that it is web based.

Ideally we would like to re-use our current model, that is, be able to logon using our existing table(s) and then pull the roles and polices afterward.

However, there is a SQL Server role and membership provider.

Would it be easier to switch the login, roles, and membership using the built in SQL Server provider and deprecate our table schema? Or should we build a provider from scratch?

1 Answer 1


As you haven't had any answers in 3 weeks, I'll offer my thoughts. Is there a business case for making this change? Presumably the existing security setup works and is well understood and therefore I would only look to change it if I could demonstrate a reason for doing so.

  • Exactly. Right now the consensus is that we are implementing our own STS that ties into our existing model, rather than employ the SQL Server built in one. That seems to make the most sense to us and we can then leverage our existing model.
    – Jon Raynor
    Sep 2, 2011 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.