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. :)
Related
I am working on an application where I need to setup identity server 4. I have an api as resource. and a web forms application as client.I have few roles like teachers, students, parents in my database. How can I use this custom database and perform authentication and authorization without using identity?
Please suggest.
From your other question here I get a better idea of what you want.
I think one solution for what you want would be to setup identityserver4 in a seperate project with its own seperate database. I noticed the tag identityserver3, but I think it is quite safe to go for identityserver4. It shouldn't make a difference for the client/user since they are conceptually compatible.
1) Give your application a client/secret (which you configure in identityserver) in order to identify your application and grant access to the resource api. Here is some information: http://docs.identityserver.io/en/dev/quickstarts/1_client_credentials.html
You'll only need to configure one client to protect your resource from the outside. The only way to access the resource api is through your application, since your application is making the actual calls. This is also the drawback, you cannot expose the token to the outside world.
Since your client isn't the actual user, you'll need to identify the user. You can use any mechanism based on your current model as you like. A simple user/pass (with or without asp.net identity) could be enough to determine the roles. But please keep in mind that your application has full access to the resource api.
2) However, since identityserver is available, why not use it? Why don't you want to use the identitymodel? I think you should consider to seperate the identity information and your datamodel. Your datamodel shouldn't be aware of the security. And the security has nothing to do with your datamodel.
When you create a seperate database for identityserver you have one place to configure the identity users. All you need is a reference (sub) to the user in the datamodel. http://docs.identityserver.io/en/dev/quickstarts/2_resource_owner_passwords.html
Add claims or roles and everything is in place and you'll see there is no need to keep identity data in your custom database. The structure of your custom database stays intact, including the user table but without the identity data.
I think this is a safer solution and considering the good documentation and sample projects it may even turn out to be a quicker solution.
The official Specifications probably don't mention this or regard it as "outside the scope of this specification".
Say we have decided to separate the auth and resource servers.
In practice, why would we want the resource and auth servers to access the same database, or why would we want to keep two separate databases - one for each server?
I'm writing this question because of Entity Framework. If I shared the same database between both sites, I figure migrations would conflict even if the auth server only touched account-related tables and the resource server only touched data (POCO) tables. (I actually haven't tried this out yet, but I don't want to waste time experimenting, so I want to hear from someone who has come across this.)
But if I separate the databases, I lose the foreign key relationship between user and the data [s]he owns - but is that even necessary? It feels like it's one of those "we did that just because" practices.
To combine them and use migrations, you'd need to have a DbContext for migrations that includes all the types used by either auth or resource servers, and use that for scaffolding migrations. This seems to be a common practice for those that require multiple contexts and want to use migrations; it's worked well for me so far.
As far as the foreign key constraints, they're just that - constraints. They enforce your business rules (that Foo.Bar must contain a value that exists in Baz.Bar) at the database level. Whether or not this is necessary really depends on your use case. Very few things are done "just because", though many things are done without full understanding - "because I saw it done like this somewhere else". The somewhere else (or wherever they copied it from, etc.) may have a perfectly valid reason, which may or may not apply to your use case.
I've used MongoDB before, but never with ASP.NET MVC.
Currently, I'm stuck trying to implement authentication for system which is going to use exclusively MongoDB (so, I don't have the option of leaving the users table to a SQL database).
Now, I figured a solution would be implementing my own Membership provider. However, that requires quite a lot of code. And, since it is related to security, it is not wise to reivent the wheel if I can avoid it.
Coming from Rails, it would be rather simple to just add something like Devise, set it up to use MongoDB and call it a day. I couldn't find anything similar for ASP.NET MVC - I am not sure if it is an uncommon use case, or if my Google-Fu is inadequate.
I don't need anything fancy -just the ability to create users, check their credentials and protect controllers from being called from unauthenticated users. Are there any packages that could solve my problem?
https://github.com/osuritz/MongoDB.Web
A collection of ASP.NET providers (caching, membership, profiles, roles, session state, web events) for MongoDB.
I would suggest to use https://extmongomembership.codeplex.com/ as this is newer provider that was presented in ASP.NET MVC4. And it contin eve more features (for instance permissions system if need)
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.
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.