Is SQL Server Sufficient for Implementing User Level Security

[vermette09]

I am redesigning our database at work to be more functional and efficient. I will be using Access 2013 and everywhere I have read says that the ULS has been totally removed and you basically have to design your own level of security and even that is easy to get around with a little bit of computer knowledge. We have roughly 10-15 users of the FE db who will be running Access Runtime but many that need specific access to certain areas, so they can't be grouped very easily. Ideally I would like to have a switchboard that groups each area (ex. Purchasing, shipping, job costing) and give users access based on those which will then take them to a "sub-switchboard" with all the reports and forms. I have read that SQL Express is free and capable of user login permissions, but it seems every thread I read about ULS, it is not suggested as an alternative and I don't understand why. Would someone be able to give me a definitive answer on the best way to have a database with user level permissions that are easy to update and modify when need be?

I didn't know if I should post this into the SQL Server forum or Security so if it is more appropriate there it can be moved.

Thanks,
Josh

[vermette09]

As I continue to ponder about this, I suppose that will still leave the reports and forms in Access so it really won't help me at all

[hapm]

I worked a lot with server side security going fine to a per record access validation divided into select, insert, update and delete permissions, and it works much better for me, than the access user system does. The very important part here, is that you secure the data, and not the frontend that represents them. The frontend in this case has to lookup the rights the user has on the server and prevent him from doing actions, that will lead to an ugly permission error. But that is cosmetic, and the only thing the user gets from tricking the frontend, is such an ugly error. Of course, the user can see the reports and forms, perhaps their definitions, but never the data that is saved and secured on the server side.
In the case where you want the user to not even see the definitions of several tables, forms and reports is either because the users have so different roles and requirements, that it perhaps makes sense to split the frontend into individual parts for each of them, or the definitions contain sensible data, that is not saved on the server, but in the frontend definition. In this case you can normally extract this data to the server, leaving the frontend as an empty hull, that only does what it should do: describing the view of data, and not containing data!

[ahnoor]

We have roughly 10-15 users of the FE db who will be running Access Runtime but many that need specific access to certain areas, so they can't be grouped very easily.



________________
NOOR