Unified System Security Design - Database / Code / Both!
-
Hi All, I'm in the middle of making a complete demo system (possibly for a new Code Project article but more for practice at the moment) whose design should be very robust and scalable. I have a question regarding security and how best to implement it, not on a detail level but a high level design bases. The security is going to be pretty run of the mill stuff, hashed passwords, users, roles, permissions. The system currently uses the AdventureWorks demo database for it's data and comprises the following components: Database SQL 2008 R2 (Express) DAL (using LinqToSQL but will migrate it to use Entity Framework) Wpf Client (using PRISM) Silverlight Client (using PRISM) WCF Services Basically I want a unified security model so that all code components (or future components) will use exactly the same security mechanisms. Which leads on to the first question. In the past I have created separate security databases and also just created tables in an existing schema to support the required security model. I would ideally like to be able to assert that the calling user has rights at the stored procedure level AND at the code level but by having a separate database for security means that that the data database starts to have a dependency on the security database which I'm not a far of. Baring in mind that there will be plenty of security going on at the code level does the database even need to worry about rights? Some projects I've worked on have insisted on this level of security. I would ultimately prefer security at both levels so even if someone managed to get a connection to it they still have barriers to getting anything meaningful out of it. Any thoughts on this or links to good reading would be appreciated. Cheers,
Jammer My Blog | Articles | DMon | SampleSort
-
Hi All, I'm in the middle of making a complete demo system (possibly for a new Code Project article but more for practice at the moment) whose design should be very robust and scalable. I have a question regarding security and how best to implement it, not on a detail level but a high level design bases. The security is going to be pretty run of the mill stuff, hashed passwords, users, roles, permissions. The system currently uses the AdventureWorks demo database for it's data and comprises the following components: Database SQL 2008 R2 (Express) DAL (using LinqToSQL but will migrate it to use Entity Framework) Wpf Client (using PRISM) Silverlight Client (using PRISM) WCF Services Basically I want a unified security model so that all code components (or future components) will use exactly the same security mechanisms. Which leads on to the first question. In the past I have created separate security databases and also just created tables in an existing schema to support the required security model. I would ideally like to be able to assert that the calling user has rights at the stored procedure level AND at the code level but by having a separate database for security means that that the data database starts to have a dependency on the security database which I'm not a far of. Baring in mind that there will be plenty of security going on at the code level does the database even need to worry about rights? Some projects I've worked on have insisted on this level of security. I would ultimately prefer security at both levels so even if someone managed to get a connection to it they still have barriers to getting anything meaningful out of it. Any thoughts on this or links to good reading would be appreciated. Cheers,
Jammer My Blog | Articles | DMon | SampleSort
My take on this is that security controled at the DB level is for the absolutely paranoid but may have its merits in some situations. If DB roles as in SQL Server are used this can be alleviated but the user (role) still has to be granted access (or a login for the user in a specific role).
-
My take on this is that security controled at the DB level is for the absolutely paranoid but may have its merits in some situations. If DB roles as in SQL Server are used this can be alleviated but the user (role) still has to be granted access (or a login for the user in a specific role).
I've actually opted for a completely different tact. I'm going to leave the database security alone as there simply isn't a one size fits all solution. I'm also going to make use of the Windows Identity Foundation and implement a claim based security model. Keeps it all flexible.
Jammer My Blog | Articles | DMon | SampleSort