I'm developing a Single Page Application using ReactJS + .Net Core 5 which has several fine-grained authorization checks.
So, in my application there are users, roles and userroles to link these two information. Then, I have a Permissions table and RolesPermissions to link the permissions (or actions) for each roles. But this diagram cannot work correctly because some roles are tailored on resources (so, I can be Editor on resource A and Reader of resource B, where A and B are the same type of resource). To summarize, some roles are directly linked to resource.
How can I manage the authorization in this case? I read on Resource-Based authorization (https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resourcebased?view=aspnetcore-2.1&tabs=aspnetcore2x#operational-requirements), but in this case the permissions design on database side would be useless and I have to write a lot of C# code to manage each possibilities (a lot of if/else). I'm looking for some alternatives... also because, after correctly managed the permisssions on backend side, I need to pass information to frontend in order to segregate the layout (for example, the button "Create" must not be displayed if you are only reader on a specific resource).
Related
We have an application (C# on the server, using AngularJS / Web Apis for a single page application) that assigns users different roles, which are stored in the database. When the user logs in, the user object (including RoleID's and RoleName) is transformed into a JWT and sent to the user, which is then used as authentication.
We're having trouble determining the best way to maintain and use these access roles however. Specifically, to use them in the current set up, it would seem that we have to hard code either the name of the role or the ID into the application.
For example, on the client side, if we want only users with a Manager role to be able to see and click a button, we would have to explicitly state that, ie if (UserService.HasRole('Manager')) { doStuff(); }.
Conversely, we'd have to do the same thing on the server side (because everyone knows relying on client-side security is bad). When the server gets a request on the API, it checks the JWT for validity and, if valid, checks the User's roll to see if they are allowed access to the specific web API endpoint.
This all seems prone to breaking if a role is renamed, or the ID changes. I generally hate hardcoding things like this. Is there a better methodology or approach that can be taken here?
In the past, when we've done RBAC (Role Based Access Control), we decouple the Role from the Permission e.g.
Role Permission
===============================
Manager Create Order
Manager Delete Order
Till Operative Create Order
Administrator Create User
Administrator Suspend User
etc.
This could be stored in a database and cached in something like Redis. Two tables, Role and Permission, where the Permissions need to match the ones built into the application (you could script this).
So your permissions grow with your application e.g. you add a new dining service, you can add a "seat diners" permission. The permissions for existing/mature bits of the software should rarely change (unless they were written incorrectly), whereas the roles are entirely fluid and can be renamed etc.
You can then use an annotation/security framework to ensure that the user making each API call on the server side has the correct role required.
You can even make it additive and allow a user to occupy multiple roles at once to blend things together.
You may maintain your user to role mapping in the database also in another table (using FK constraints) or you may use something like LDAP with the mapping being looked up from the DB/cache.
On the server side, Microsoft has built in management for roles. I would first look at
http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity
And then I'd also look at the the IdentityServer project for working with JSON Tokens on the server side.
https://brockallen.com/2013/04/14/getting-json-web-tokens-jwts-from-adfs-via-thinktecture-identityservers-adfs-integration/
On the client, I would suggest storing the tokens as either just in memory javascript or if you want them to persist, I would store them as cookies but make sure to set the cookies to not be accessible by JavaScript by using the httponly parameter when creating the cookie.
HTH's
I am using a stateless design for a MVC5 Web API 2, ASP.NET application.
User roles are created by administrators by selecting permissions.
Each user in the application is assigned a custom user role, one role may be shared amongst users.
Razor views are structured based on the permission in the users role.
MVC and API controllers are available depending on the permissions in the users role.
For each request to the server, the users permissions need to be processed.
I can think of 2 ways to do this:
Store the id of the users role in the Role claim and perform a database lookup to retrieve the permissions for each page-load/request.
At the user login, retrieve all the permissions assigned to the users role, serialise them as JSON and store them in the Authentication claim. Then at each page-load/request, de-serialise the JSON back into objects and process the permissions.
Which of these would be the better option?
Option 1 is a lot slower than option 2.
Is there a security risk of storing the permissions in the cookie?
Is there a better or alternative solution which is quick and secure.
Storing permissions and other sensible data inside a cookie is always a very bad idea as it's quite easy to manipulate them. Trusting cookies requires an additional server-side check which defeats the purpose of storing it inside a cookie.
You're way better off only trusting the data that is under your control, aka the data in your database(s).
Depending on your application it might be useful to lazily evaluate permissions only when you really need to access them if the performance hit is too big. Keep in mind that you can make use of things like Redis to improve performance dramatically.
So again, depending on your application I'd probably go for option 1 as it's the more secure way.
I am new to ASP.NET and I am working on ASP.NET Web Site Application in which i have some Internal (OR Domain specific) Roles. Like, BoardOfDirectors, Managers, Secretary belonging to Employee class and ShareHolder another Role, another one as Company Administrator/Creator/Owner etc. All these Roles are internal (OR domain/business model) specific Roles which delimit the business functions a specific Role/Actor can perform.
One of my colleagues told me to do R&D on ASP.NET Forms-Based Authenticatoin, Authorization and MEmbership class etc. With this i initally got an idea that probably ASP.NET provides a ready-made Role Management Module that can be customized to any domain specific needs (just as we see in ready-made CMS Systems)
But, After some googling, i reallized that Form-Based Authentication limits the Roles on use of Web Resources specificlaly Pages. This leads me to idea that Internal (OR Domain Specific) Role Management is not related to ASP.NET Form-Based Authentication. Instead Form-Based Authentication (as it restricts access to pages in website) can be used to manage External Roles of the website like Web Site Adminsitrator (Having a different website folder/file structure which should be accessed merely by a Role specified in database like Site Admin or so. Similarly, Form-Based Authentication can be used to discriminate between a Site Member and Free User/Visitor.
For my internal/Domain specific Roles, I really do not see any reason to create multiple pages in different Role-Based folders with duplicate OR overlapping functionality like A Company Creator will be able to do business functions that manager can do, so i would not like to create two separate folders/files; one for Company Creator and other for Manager with Manager page duplicating some of functionality from Company Creator. I feel that it would be appropriate to handle Domain Roles using Business Logic (in my Domain Model Layer).
I need your suggestion if i am wrong in my understanding/assumption, OR if i am missing something?
Regards
Do not mix up Authentication and Authorization.
Authentication in your case is going to be done by using Forms-based Authentication, and Authorization is going to be based on User Roles.
Authentication would ensure that the system recognizes the User. Authorization would ensure that whether or not that user is allowed to perform certain actions or functionality.
The Problem
I'm an ASP.NET newb who has been given the task of creating a multi-user password management system for use within a secure intranet. Essentially the user will be automatically logged in via windows authentication, which will then provide them with an appropriate view depending on their group. For example, a user of group 'admin' would be able to access all password entries, and a user of group developers would be able to access all password entries belonging to users in the 'Developers' active directory group. Users should be able to create, update, and hide (delete) password entries.
What I have so far
So far I have essentially been figuring out what will and will not be impossible, and researching technologies. Windows authentication itself appears to be easy, however it breaks when I enable the role provider, which appears to be necessary for providing different views for users. By 'breaks' I mean specific users are still recognized, but entire groups are not.
The different views must be automatically served, and I have come up with two techniques to do this:
Checking the role (group) on the home controller, and serving the appropriate view. This would require a long list of messy 'if' statements, however.
Serve a common view and allow or disallow viewing certain elements according to group. This would require putting a lot of logic in a view, which is as I understand inappropriate.
There will be a password.cs model class which will hold all information on a password entry including which groups should have access to it. I cant really think of any other necessary models, as the user information would not need to be stored.
Security concerns
I understand that storing such sensitive data in a single location could be a recipe for disaster. Passwords will be appropriately encrypted using pre-exising libraries which I have access too. I will have help with this area. Also, passwords will not be view-able as plain text on the system to avoid shoulder-surfing, but will be displayed as asterisks and will be copy-able to the users clipboard.
My questions
Essentially I would like some advice on how to structure the system and the most simple ways to enable active directory authorization with windows authentication. I would like some advice on how to provide the appropriate view for the user, and how the different areas should fit together. I am not expressly asking for any help with the password security side of things, but any insight or discussion would be warmly welcomed. Essentially, I would very much appreciate any help, links to tutorials, or suggested readings.
My tools
At my disposal I have Visual studio professional 2010, MVC 4.0 and .NET framework 4.0, and standard (non-admin) access to the server.
I will be able to give experimental code which I currently have in place tomorrow (It's 22:30 GMT, I'll be back in the office tomorrow morning). Let me know if you need any more information.
I have implemented two solutions where I had to integrate MVC with Active X Directory. There are multiple solutions (e.g. Security Application Block from Enterprise Library). However, I ended up using AzMan and the RoleManagerAzManProvider. I ended up with this combination because I did not need to deploy any additional libraries.
I started with this article: [http://msdn.microsoft.com/en-us/library/ff649313.aspx][1]
Even though it is written for ASP.NET, I was able to use it for MVC. I placed my XML Local Policy Store underneath app_data and configured the web config
<add name="LocalPolicyStore" connectionString="msxml://~/app_data/MyPolicyStore.xml" />
This worked out nicely for me because the Policy Store allowed me to define Application Roles and, when deployed at my client, map those roles to AD Accounts.
After that, I implemented a custom Authorize Attribute that I registered in the Global filters. This is where I made the decision which page the user would be redirected when they logged into the app. Finally, I used the standard Authorize Attribute on controllers based on group names.
I have thought about writing a set of Custom Editor Templates and Display Templates that would take roles into account so that I can render different UI for controls based on the User's application role (render a span instead of input).
Although your application is probably already written, I hope this helps.
Chuck
I am developing an MVC3 application and I have gotten to the point where I need to start securing out different areas of the intranet site to particular users.
The site is being used on the intranet and uses windows authentication for login.
Within the database I have a users table which contains numerous fields that determines the users role. This is maintained in the admin area of the site.
Certain users will have the ability to access the admin area, some users will only have the ability to read certain areas of the site but not contribute, etc etc. There are some complicated business rules.
I am looking for how to secure out different areas. I have read a good few articles around using the authorize attribute on controllers for particular groups, this doesn't seem to be a good fit as I understand it I would have to control what users are in what groups from within the configuration of the application whereas the admin users of the application should be ones controlling this via the application itself.
Any suggestions are welcome.
If you are mainly concerned about managing users, ASP.NET does a great job of this with their built-in Web Application Administration Tool. On the top-right of the Solution Explorer, to the right of the refresh button, is a hammer-and -earth tool that you can click on. It allows you to manage users and roles, and from there you can assign the users to roles. Perhaps your admins can use this.
This tells you how:
http://www.asp.net/mvc/tutorials/mvc-music-store/mvc-music-store-part-7
As far as having to put authorize attributes on the controllers/methods, I don't see any way around that. Let me know if I have misunderstood your question.
Assign users to roles and use AuthorizeAttribute.