Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

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.

share|improve this answer
    
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 '11 at 15:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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