October 12, 2009 at 3:03 pm
I am involved in a project that involves creating a web app (MVC) for CRUD actions in a database. There are a few different levels of permissions (pretty standard fare here) and a future need to restrict access by location (for example, only allowing a certain user access to data from just from Illinois). I thought that this type of thing would be best handled by using the users, roles and profiles and setting the permissions based on the assigned role with some profile settings handling the location issue.
But we have another developer who's set up a system that uses Windows authentication, stores the user name in a table that is joined to another table that defines each DB table and the permissions for that user. So every time the user goes to another form, the app pings the permissions table. It doesn't sound that different than the ASPNET accounts DB in a general way, but I just don't understand why this manual system is an improvement over the provided structure. It just seems like additional dev time to reinvent the wheel and a huge potential problem when we have to provide access to users outside of our group.
My question is this - is setting up this type of manual system a good idea security-wise or application-wise? Is there a reason not to use the ASPNET users/roles structure for an ASP.NET site, MVC or otherwise?
Thanks for any thoughts,
Scott
October 13, 2009 at 9:10 am
So I've already come across one flaw in the manual table option - the system picks up different logins (due to some domain issues that I have no control over) seemingly at random so that the user name can change from page to page. For example, I have a user with an AD account that can handle myname1 and myname2, which works fine for system logins. But when logging in to the web app using myname1, sometimes the security provider returns myname2 as the login. Since myname1 is the user name in our account table, the permissions check fails.
That doesn't qualify as a functional login system to me. Anyway, sorry if this is in the wrong forum. I still just don't understand why someone wouldn't use the membership providers.
Scott
October 13, 2009 at 10:00 am
There is only one main reason that developers like security to be data driven, is that depending on the app, they can code functionality into the application that allows permissioning to be handled through the frontend rather than involving a dba. they argue that it is easier to allocate permissions this way and allows greater flexibility in creating custom permissions. However with the more recent versions of SQL Server, permissioning can be taken down to a more granular level.
Ultimately it is down to who wants to do the more work, either the DBA with allocating database roles for generic access and object and statement permissions for more custom/restricted access.
Or the developer who can just add a few rows to a table and more code to the application.
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply