I'm building my first MVC5 application for Azure and have tracked down all the parts and pieces I need to put it together (User accounts, scaffolding, roles, etc) except one. I need to have users placed in "workgroups" and each user in the workgroup can only see the data associated with that workgroup. For instance, if I have a simple Cars model, users in workgroupA can add/remove/change cars but only within workgroupA. Users in workgroupB would not see any of that data at all when they log in.
C# programming isn't an issue for me, just getting familiar with MVC5. I have previously accomplished this with Django and its built in group management, but need to move to MVC5 and can't seem to find an example that gets me close enough. Can anyone point me toward the best practices for this?
Related
I’m currently building an ASP.NET MVC 5 EF6 blogging web application.
I have two databases and contexts :
-a database for the actual data of my application (blog posts, blog categories, tags, etc) .
-a database for authentification and membership purpose (users and roles).
I am able to authorize a given user the right to add/edit/delete blog posts, using the authorize attribute in the BlogPostcontroller :
[Authorize(Roles=”Administrator,Author”)]
and it works pretty well..
MY GOAL : let’s imagine I want to grant an user the right to add/edit/delete a subset of all the blog post or blog categories (let’s say only to the “Cooking” and “travel” blog categories).
I started to think about creating a navigation property between the user and the blog category entities, but apparently foreign keys between two separate databases are not supported by the entity framework.
Do you guys have an idea of a walk-around for this problem?
Your help will be much appreciated.
This is what you need.
http://typecastexception.com/post/2014/02/19/ASPNET-MVC-5-Identity-Implementing-Group-Based-Permissions-Management-Part-I.aspx
Basically, the privileges is what you will need to configure and associate user roles.
If you want to keep your authorization data separate from your business data, i.e. in 2 separate databases where one contains user information and permissions and the other contains your blog data, then what you actually want to achieve is externalized authorization. That's actually a great intent. After all, do you keep authentication information with your application data? Of course you don't.
Different frameworks give you externalized authorization capabilities. For instance, in .NET, you have claims-based authorization.
You can also take a generic approach and use XACML, the eXtensible Access Control Markup Language. XACML uses attributes (it's an attribute-based access control model as opposed to simply role-based) and combines them into policies & rules to define what can happen. For instance, with XACML, you can write the following rule: A user can edit blog posts he/she owns.
In XACML, you have the notion of an authorization engine called the Policy Decision Point (PDP). That PDP links together all the information it needs to make decisions. In your case, it will use the 2 separate databases and create the relationships on them.
Now, if your use case is simple, using XACML might prove too much. In that case, just use claims-based authorization.
I must have missed this somewhere (or slept through the class)... the standard ASP security tool for managing users and roles seems to be absent when using the new simple security version. That is, the original is there and working, just points to traditional ASP security... NOT to the new "simple" system.
In my project I can log in, I can look at the webpages_ tables but can find no method of accessing them in my project... I would be happy to manage roles and get the USERID and maybe ROLEID so I could tie the user to other functions in my project.
I've looked through hundreds of posts and articles... normally I find I am missing some minor config entry or something but this time I am a little more stuck.
Advice is appreciated.
Thanks!
SimpleMembership does not work with the Web Site Administration Tool (WSAT). There is a good overview of SimpleMembership in this blog. Here is a quote from it.
WSAT is built to work with ASP.NET Membership, and is not compatible with Simple Membership. There are two main options there:
Use the WebSecurity and OAuthWebSecurity API to manage the users and
roles.
Create a web admin using the above APIs.
Since SimpleMembership
runs on top of your database, you can update your users as you would
any other data - via EF or even in direct database edits (in
development, of course)
I would also add that you can seed some of this information at application start-up, such as what roles are available, as shown in this article.
I am working on designing a web application for our customers where each customer has a unique portal into the system. Each customer needs to be able to manage their own set of users without concern for other customer's users, thus two different customers need to be able to both have a user jasonsmith.
At the same time, one customers show NOT have any knowledge of the other customer's existences, nor that this is a multi-customer system.
What are the standards today for implementing such a system? Where should I go to learn more about how best to implement such a system.
What you are talking about is called multitenancy.
There are several approaches to this.
Most common approaches are:
Single database
All tenants share the same database. You'll therefore have one tenants table with the information about all tenants. All other tables uses the tenantid as a foreign key.
The problem is that you have to make sure that the user only accesses it's own information (the user can for instance try to change the id in the uri). You'll therefore have to validate each object that the user has tries to access.
Multiple databases
Some database engines (like RavenDB) can handle several databases without a problem. That means that each customer get's its own database (which you load at the beginning of each request after the user have been identified).
So you'll have one db users during the authentication to be able to identify the tenant and one database per customer.
The upside with this solution is that it's impossible for the tenants to access each others database. (unless they've hacked the account)
Currently working on a web application in ASP.NET, MVC3 that allows people to view items, and change anything. This is with using my own database that I have created, but this I have found is good for generally viewing anything on the application but not good for security purposes to prevent them seeing particular things, and I do not want to waste my time removing tables and re-adding them.
So... Is there a way to communicate between the ASPNETDB and my own Database which would allow users to login to the web application but also sign up as a customer?
I would solve this using database roles, and only grant the appropriate roles to the user used to login to the two databases.
You have very granular control over what you want a db user to have access to.
Read up on databases and db roles
I am creating an Asp.net MVC application and I'm currently using the built in Authentication/Authorization code that comes with the sample MVC app. For the most part this is working ok and I kinda understand what's going on.
What's concerning me though, is that now I kind of have my users stored in two different tables across two databases. i.e. I have users in my App's database that represent the "Customer" entity in the application, as well as the "User" in the Authentication database that's used to log in someone to the app.
Should I take the logged in user's User.Identity.Name value and do look up in my Customers table or should I merge them into one table? What's the best practice way of handling this?
Please forgive my ignorance - this is the first time I'm working with a system like this.
Any feedback is greatly appreciated!
It's helpful to think of credentials and the records that associate a person to application data as two very different things. Depending on the application, your Customer may not have credentials to log in or you may have an administrative User that logs in but isn't related to your application data.
Separate credentials are also useful if Users access more than one application with different rights for each.
For these reasons, I'd keep Customer and User separate and look one up from the other where appropriate.
You can extend the .Net Membership Provider to take all the information you want and post back in a single model I think.
See this one ASP.net Profiles and Membership - Custom Providers or should completely I roll my own?
And this one How to implement ASP.NET membership provider in my domain model