In my organization, we are just beginning to use the Entity Framework for some applications. In the past, we have pushed developers to utilize stored procedures for all database access. In addition to helping with SQL injection, we tried to grant logins access to stored procedures only to keep security relatively tight.
Although inserting, updating, and deleting are easily done through stored procedures in the EF, it appears to be difficult to use stored procedures to query data with EF. However, using LINQ or Entity SQL and allowing EF to create the queries means giving a user read access to the entire database.
How have others handled this dilemma?
What kind of data protection are you trying to apply?
With EF, you can write a unit testable business logic layer that will handle many more authorisation scenarios than you can do at the database layer (although I can see how multiple layers of security makes you feel safer):
Querying AD (is this user the manager of that user?)
Calling web services
Checking other environmental contexts
If your circumstances mean you're not ready to think of the database as a store for data rather than a security & business logic layer, then maybe EF isn't right for your project.
P.S. EF will protect you from SQL injection.
Related
We have a DB2 database which is used by legacy applications that we are in the process of decommissioning and we have an Oracle database that we are developing new applications for. In order to maintain compatibility with legacy applications until they are completely decommissioned and keep data in sync, we are using Atomikos for two phase commits. This however is resulting in a lot of duplicated entities and repositories and thus technical debt, because the same entities and repositories cannot be used by the same entity managers so we have to duplicate them and put them under different packages for the entity scanning.
In most cases we want to read data from the legacy database and persist to both, but ideally this would be configurable.
Any help on this would be greatly appreciated.
I am reading up on my security and have a general question.
In a database, users should be granted the only the attributes that they require i.e. select, read, delete etc.
When using Entity Framework as the ORM how can I implement this?
The entities have no concept of permissions.
Thanks
The way you implement least privilege for Entity Framework is that you use a database login for your connection to the database from EF (typically this would be set in the connection string). Depending on how you use EF, that login should only be allowed to do certain things.
Obviously it will need CRUD access to the tables (or views), unless you're using stored procedures for inserts/updates/deletes. It'll need execute on any functions or stored procedures you use.
Also, if you intend on using Code First Migrations, it will have to basically have ownership because it will be adding/removing tables and columns.
Now, that is how you implement least privilege for EF, which might not be what you're even looking for. If you're wanting to know how to implement it for your Users, then that would be a question of authentication and authorization, which would be outside the scope of the database and would be more of an issue for your Application. (I guess technically you could use a method where the user has to log in using a database login, which would be used to configure EF's connection to the database, but I think that would tend to be very error prone, especially if it's in a web application.)
Let me know if that helped you out. :)
We have a couple of large, mature apps installed in hundreds of medical clinics. These apps are built using Windows Forms and WPF and although we host the database for some of them, the majority of our clients have a local install of the database.
We are in the planning stages of rebuilding our application on the ASP.NET MVC platform using Entity Framework. We will also be re-architecting our database, but for reference, the current database has about 600 tables and 1900 stored procedures. Although we don't have an official DBA, we have enough DBA skills to build and maintain what we have, so we are capable of designing and building the data model ourselves. Also, we will continue to have both on-premise and hosted solutions.
Our struggle is with deciding how to use EF. We're all in agreement that we should use code-first, but some of us think we should build our classes, decorate them with attributes, and allow EF to generate the database for us. Others think we should design and build the database and then generate code-first POCOs.
Assuming we will have non-CRUD stored procs, triggers, views, stored procs, and user defined functions, is database generation a reasonable approach? Are there reasons why it might be the preferred approach? Any good reasons for avoiding it altogether?
I got an existing database with many tables which are accessed using stored procedures only (no O/RM). I'd like to create new tables in this database using Entity Framework and the Code First approach.
Do all the tables in my existing database need to be modelized in my Entity Framework classes? Will I be able to hand-code only the new classes I need in my DbContext? Other tables really need to stay untouched and away from O/RM for the moment.
Note: I'm going to be using the latest EF5.
As for now the Power Tools only allow you to reverse engineer all tables and views in the DB, which can be a problem if you have a big DB, with hundreds of objects, you do not want to reverse engineer.
However, I found an easy workaround for that:
Create a new technical user for the reverse engineering. To this user you only grant permission to the tables and views, that you want to be reverse engineered.
Have fun!
You are under no obligation to map any given table with EF. If you already have a database, you may want to consider reverse-engineering your database with the EF Power Tools available from Microsoft. I did this recently with a MySQL database that I had for testing purposes and it worked quite well!
If you are new to EF an advantage is that the PowerTools write a ton of code for you, which will help you get a grasp on the syntax of Code First. You will need to modify the output but it is a great start. I really believe that this approach will give you the least headache.
The EF PowerTools can be found here: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/
I need some opinions.
I'm going to develop a POS and inventory software for a friend. This is a one man small scale project so I want to make the architecture as simple as possible.
I'm using Winform to develop the GUI (web interface doesn't make sense for POS software). For the database, I am using Postgresql.
The program will control access based on user roles, so either I have to develop a middle tier, using a web server, to control user access or I can just set user priveleges directly in Postgresql.
Developing a middle tier will be time consuming, and the maintenance will be more complex. So I prefer to set access control directly in the database.
Now it appears that using database to control user access is troublesome. I have to set priveleges for each role. Not to mention that for some tables, the priveleges are at column level. This makes reasoning about the security very hard.
So what I'm doing now is to set all the tables to be inaccessible except by superusers. The program will connect to the database using public role. Because the tables are inaccessible by public, I'm going to make publicly accessible stored functions with SECURITY DEFINER (with superuser role). The only way to access the tables is by using these functions.
I'll put the user roles and passwords in a table. Because the user table itself is inaccessible by non-superuser, I'll make a login function, let's call it fn_login(username, password). fn_login will return a session key if login is successful.
To call other functions, we need to supply session key for the user, e.g.: fn_purchase_list(session_key), fn_purchase_new(session_key, purchase_id, ...).
That way, I'm treating the stored functions as APIs. Adding new user will be easier as I only need to add new rows in the user table rather than adding new Postgresql roles. I won't need to set priveleges at column level. All controls will be done programmatically.
So what do you think? Is this approach feasible and scalable? Is there a better way to do it?
Thanks!
I believe there is a better way to do it. But since you haven't discussed what type of security you need, I cannot elaborate on specifics.
Since you are developing the application code in .NET, that code needs to be trusted (unlike a web application). Therefore, why don't you simply implement your roles and permissions in the application code, rather than the database?
My concern with your stated approach is the human overhead of stored procedures. Would much rather see you write the stated functions in C#, rather than in PostgreSQL. Then, standard version control and software development techniques could apply.
If you wait until somebody has at your database to check security, I think you'll be too late. That's a client/server mentality that went out at the end of the 90s. It's part of the reason why n-tier architectures came into vogue. Client/server can't scale horizontally as well as an n-tier solution.
I'd advise that you take better advantage of the middle tier. Security should be a cross-cutting concern that's further up the stack than your persistence layer.
If the MANAGEMENT of the database security is the issue, then you should add the task of automating that management. That means that you can store higher level data with the database tables, and then your application can convert that data in to the appropriate details and artifacts that the database requires.
It sounds like the database has the detail that you need, you just need to facilitate the management of that detail, and roll that in to your app.
My honest advice: Do not invent POS and inventory software. Take one of existing projects and make it better.