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.
Related
I am using ASP.NET WebAPI with the built in authentication and identity services that come with the Visual Studio template. I now have it that a user can access the system and be authenticated.
The next logical step is to allow the user to create records. Lets say the user can have a "Project". How can I associate the user with a project at the point the project is created? It seems logical that the project table will just store the user_id provided by User.Identity.GetUserId().
Now, say that a project consists of Tasks. By default the WebAPI will create a Tasks controller, where I post a task. I think I would need to inject some additional information (such as the project id) at the point of creating the task.
But, say someone wants to add a task a project that doesn't belong to them. I need to verify this by loading the project, and checking the user_id field. Now I am adding two repositories to my controller. This seems like a lot of work.
Is it my own laziness that makes this seem hard???
I think this might be a related question, as it seems like you are looking for record-level authorization.
MVC / ASP.Net Best Practice for Record-Level Authorization
There is merit also in using multiple repositories. See here for an example of use.
http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
Here, you would wrap the multiple repositories up within the UnitOfWork class.
I hope this points you in the right direction.
I'm working on a multitenant project management application in ruby on rails and am a bit bogged down with implementing access for users who might not belong to a specific tenant.
For example we have the users Bob and Martha and they belong to a tenant A - alternatively there are two other users namely Jim and Jill who belong to Tenant B. Now we have a client called Mark who is a client to both tenants. Both tenants have projects and I need to build in an accessible form for the client so the client can sign in and view his projects. The thing is that I don't want and obviously no client would want a seperate login for each tenant here. I'm interested in coding the tenant management by myself here however I'm a bit bogged down on how to implement this.
I'm implementing row based tenancy i.e every model would have a reference to the tenant model here and signed in users can edit and add whatever belongs to their tenant. However with respect to a client or a possible case of a consultant user who might require access to more than one tenant - how do I set up the structure here.
Ideally a client would want to be able to sign in and view a list of all projects differed by tenant/company. How can I set up this structure? Also I want to keep this open ended such that it is possible that a user from TenantB might also be a client to TenantA.
The thing is that I don't want and obviously no client would want a seperate login for each tenant here.
They actually do want this, mainly for legal, auditing or security reasons.
Multi-tenancy exactly means the separation of data. So during login or right after that you choose a tenant. After that you only see data exactly of this tenant. There is no break-out later: It's possible to switch to another tenant, but not to merge data of different tenants.
If this is not what you want, consider to redesign your data model: There could be assignments between projects and persons. Customers can have their "own" projects by having a foreign key in projects linking back to the customer. This data model approach differs from using a multi-tenancy approach which is actually a technical means to separate data on row or instance level.
I use devise for authentication and have assigned a role for each user. I have one more model posts which contain number of posts. I want to restrict one user of the role employee to view the specific post and the same user to view and create the different post. How can I do this?
I realize I am late to the battle here.
What you are looking for is an extension to role-based access control. RBAC cannot cater well for your scenario. You need to consider attribute-based access control. CanCan and Devise are two language-specific frameworks that address attribute-based access control.
If you want a broader, more generic ABAC solution, then consider XACML, the eXtensible Access Control Markup Language, which is a standard defined by OASIS much like SAML is.
XACML gives you:
attribute-based access control: attributes can be used to describe pretty much anything (users, objects, resources, context, time, actions...).
policy-based access control: policies bring together attributes to define authorization. For instance employees can view the posts of employees in the same team and can edit posts they own.
fine-grained access: it is possible to define very specific and granular authorization policies
support for segregation of duty
language-independent authorization: it works for Java, .NET, Ruby, Python, and more...
centralized policy management
Here are some interesting resources to learn more:
NIST RBAC model
NIST ABAC model
OASIS XACML website
Check out this tutorial which specify the ability to define logic to control the user activity
https://github.com/EppO/rolify/wiki/Using-rolify-with-Devise-and-Authority
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
I'm using Ruby on Rails for an internal site. Different users of the site have access to a wide variety of data and highly disparate perspectives of the data. Within those different classes of users, there needs to be levels of access. Within the levels of access I need to be able to add features from other classes of users.
In the released "Version 1.0" of the intranet site I have implemented the general classes of users. I am now needed to implement much finer-grained control of a users access.
The question is how?
What is the generally accepted practice for coding up user preferences (display the map (or not); access to this feature, but not this feature) without exploding the database schema and populating the view code with <% if feature_allowed %> tags everywhere.
Another totally different approach would be to use acts_as_authenticated and authorization plugins. The tables will be built by the plugins (ie users, roles and roles_users). From the doc:
The authorization plugin provides the following:
A simple way of checking authorization at either the class or instance method
level using #permit and #permit?
Authorization using roles for the entire application, a model class, or an
instance of a model (i.e., a particular object).
Some english-like dynamic methods that draw on the defined roles. You will be
able to use methods like "user.is_fan_of angelina" or "angelina.has_fans?",
where a 'fan' is only defined in the roles table.
Pick-and-choose a mixin for your desired level of database complexity. For
all the features, you will want to use "object roles table" (see below)
populating the view code with <% if
feature_allowed %> tags everywhere.
I don't think you want to do that. Assuming none of the alternatives suggested are practicable, at the very least you should consider shifting those checks into your controllers, where you can refactor them into a before_filter.
See section 11.3 in "Agile Web Development With Rails" (page 158 in my copy of the 2nd edition) where they do exactly that.