I'm building an application for which I want to use roles managment applicable to individual pages. That is, restrict users' access to pages based on their roles. These roles are stored into the database, as the users. This is the PHP way of doing things and I'm trying to port this to ASP.NET
What I need is that someone can point me to the right resources to look at to acomplish the above task. Until now I have not been able to find what I am looking for.
Thank you.
I think you should checkout the ASP.NET membership provider model:
http://msdn.microsoft.com/en-us/library/sx3h274z.aspx
If you are looking for fine grained control then take a look at Rhino Security
Related
I have followed a wonderful tutorial by Microsoft on creating a MVC web app using Core 2.2 (https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-mvc-app/?view=aspnetcore-2.2). After completing this tutorial I was able to build a similar web app using a different product. For simplicity I will stick with the "Movie App" example from the tutorial to ask my question.
Below is the view of the basic CRUD application created.
I would like to provide some basic security for the web application. So far I have been unable to find a solution that meets my needs which are as follows:
Simplicity. There will be only one user who needs any privileges and that is me. The privileges will be full use of CRUD features (I am the only one who can click on any of the blue link in the above image).
No login requirements for the public. I would like anyone who visits to be able to be able to make a query from the search box (not shown in the picture) and see the results. I just don't want them to be able to make any changes.
Not to have to spend too much time on security so I can continue learning in areas better suited to newer developers.
The bulk of the options I am finding are enterprise level, complex beyond my skill level at the moment, or require everyone to be a user. If I am the only user is there a way for me to easily create one user account and maybe a second factor like an IP lock? If not is there a better approach for me to take in tackling this issue?
OK, one thing you have to implement is "some" kind of security / Login - so that the application knows "someone" has logged in. In your case, it needs to know that "you" have logged in. So you have to implement some kind of basic Authentication mechanism, so that the user "identity" is known. You can take a look at basic cookie authentication here. You don't need to implement any major claims system - a simple authentication is enough (for your non production / learning scenarios).
Once you have implemented some kind of authentication / login system, after a successful login (authentication), the system knows that the "user" is authenticated. Then in your Razor code you could simply check for this condition & then remove the links for Unauthorized folks & on controllers you could add the "Authorize" attribute so that back-end code also checks for authenticated users for relevant functionality.
eg: In Razor code, you could include conditional links to Edit / Delete etc, like so:
#if(User.Identity.IsAuthenticated)
{
//Include links for Edit / Delete
}
And you can include a mix of [Authorize] attribute on relevant controllers and [AllowAnonymous] on relevant methods.
Hope this helps. There is no escaping some basic understanding & work.
We are currently building architecture for thin-client bookkeeping application. It should follow two main requirements:
Application should have module design. Each module can have (and they actually do have) own Role system.
Later application should be adapted for running using different databases on different machines.
We think Asp.NET MVC 3 is appropriate platform for this task. For managing application data we chosen latest version of Entity Framework - its batch of Data Providers and Code First feature can save us much time.
The part we are tangled with is user/role management system. We should have some kind of Global Administration section for adding users and giving them access to modules (only global admins can add user to the system, no "guy from street" registration supported) and each module has its own administration section with its own admins and roles. We already have data model to store everything we need in appropriate way but have no idea how to access this data correctly from application.
Currently we see two possible ways to resolve this problem:
To write custom Membership and Role providers based on our DAL. Nobody from our team have done this before so we are not sure if this way worth the trouble. Membership provider cant offer as much flexibility as application needs so some crunches would be needed.
To dig through some obsolete books to find out how web sites administration system was organized before Membership providers where created.
Both this ways are not elegant and not obvious for us and its not an easy question which way to choose. Also we do believe that it can be other solution (of cause architecture can be affected). So, we would be glad to see any suggestion connected to this problem.
I'd personally recommend using the standard membership provider for creating and authenticating users in the first place, and then once you've verified that the user isn't just some "guy from the street," use your own custom architecture to verify that the authenticated user has access to the controller and action that they're trying to access.
The built-in membership provider takes care of a lot of nuances with regard to user authentication, password storage, and such. It uses best practices to avoid brute force attacks, rainbow table attacks, etc. It's tried and true.
But it sounds like your per-module permission structure may or may not fit the mold of the ASP.NET Role Providers. If they do, that's all well and good, and it'd be a good idea to implement a custom role provider. But if your needs are "outside the box," you'll probably be better off just manually checking rights at the point that's most appropriate for you (controller, action, request filter, etc.).
I would encourage you to use a custom membership provider. Why? Cause its the standard way and will save you tons of works. It's not as hard as I might see and there are tons of resources like this one.
To write custom Membership and Role providers based on our DAL.
Nobody from our team have done this before so we are not sure if this
way worth the trouble. Membership provider cant offer as much
flexibility as application needs so some crunches would be needed.
It is very much worth the trouble, if the default ones do not provide the functionality you need. If you already have a complex user system in your database, a custom membership provider is probably a good idea.
It will add valuable experience to your team, and you should be able to reuse much of the code in your next project. As #Randolf mentioned, there are loads of good resources for building a customer Membership provider, and I speak from some experience when I say that it is not really all that difficult. Everything is there, you just need to implement some methods.
Well, finally we decided write all from scratch and it was easier that it seemed to be
Add own IPrincipal implementation. Additional fields and completely different logic for IsInRole() method to avoid writing own attributes.
Assigning our IPrincipal in Global.ajax event to User.
It wasn`t hard at all. Now we have all the flexibility we wanted. No providers involved.
I have checked the following article on how to use the sqlMembershipProvider. My question, is this the way most of the asp.net applications authentication schemes implemented.
Is there any other method, any references will be quite helpful for me.
Edit1:
My intention is to know the other possible ways, I can authenticate a user against a standard database.
"Most" is unfortunately hard to quantify.
MSFT has made it easy to setup an ASP.NET application using SqlMembershipProvider for an out-of-the-box setup, making it super easy to get authentication against a SQL db working.
That said, I rolled my own, because I didn't need much of what the built-in stuff was doing.
The way I did it was to write my own membership provider class, and use the web.config to specify that my customprovider was the default membership provider.
For ASP, there are other ways of doing authentication, such as using NTLM (basically creating windows users for each web user, and using Windows built in authentication).
Short answer: If you can make use of SqlMembershipProvider, and it does all that you need, then I recommend using it.
I reckon #Alan (+1) makes good points.
On a simple level if the (trusted) framework you are using offers you a solution that needs configuring rather than coding and it covers your needs unless there is a compelling case against it then it is probably a good solution.
You wouldn't write a new textbox control in asp.net, or a new fadeOut method for jQuery - you would use the provided solution.
I've rolled-my-own in this area and used all kinds of plug-ins and third-parties over the years. But in the project I'm currently working on we needed user authentication on Tuesday of last week and with SqlMembershipProvider the security module was complete by Wednesday. That's good enough for me!
Is there a standard object I should use to edit Users and their Roles in ASP.NET? Or should I role my own?
This is one is fairly feature rich and well documented...
http://mywsat.codeplex.com/
What about following classes
MembershipUser
MembershipProvider
EDIT:
The Roles frameworkâs functionality is exposed via the Roles class, which contains thirteen static methods for performing role-based operations.
CreateRole and DeleteRole methods will do the job.
Reference : http://www.asp.net/learn/security/tutorial-09-cs.aspx
If you need a custom implementation of the built-in functionality that you can modify to suit your needs you can find one here
There is a built-in web site administration tool that works well locally: http://www.developer.com/net/asp/article.php/3569166/Configuring-Your-ASPNET-20-Site.htm. This shows an IIS administration tool, but I have not used that so I don't know how well it is. But that again would require logging into the server.
For our app, we built our own because we needed something more robust anyway, at least for the users/roles part. I haven't seen anything personally. You could try checking out the codeplex.com site, I remember seeing some things in the past, but never researched/experimented.
HTH.
Use the standard Membership and Role providers framework for the backend. There are two out-of-the box Membership providers that handle authentication against the DB or Active directory (SqlMembershipProvider and ActiveDirectoryMembershipProvider). There are a couple of out-of-the box Role providers as well (SqlRoleProvider, AuthorizationStoreRoleProvider, and WindowTokenRoleProvider).
For the front-end, the Logon controls are standard and interact well with the Provider framework...but only for login and changing passwords.
To my knowledge however, there are no standard GUI controls or wizards that have out-of-the box functionality for editing and administering users. You'll have to roll your own pages for that.
I wrote a couple of custom aspx pages.
I have a website that show info to all users but if you are logged in you get access to more info and pages then unlogged user does.
Can i use some sessions variables and include them in each of the pages ?
What is the best way to do this.
Also, what is the best way to make user stay logged in, sort of "Remember me" checkbox. Save a cookie on hdd ?
To answer your first question. The easiest route to go is to have something in your code behind that sets the visible flag on or off of certain controls based on something you've saved in session.
This can get complex fast, so I would play with it a bit and figure out what works best with your business rules.
To answer your second question. You should save something in a static cookie that you can reference later. I personally like saving a GUID in their cookie, which I save a copy of in a local database. When someone re-visits the site, I look for this cookie. If the GUID is present and matches one stored for someone in my Database, I auto-log them in.
I would recommend using ASP.NET Membership. It has a Login control with a "remember me" function. You can also restrict access to pages via the web.config with it.
This is a good series of articles on the subject: https://web.archive.org/web/20211020153319/https://www.4guysfromrolla.com/articles/062508-1.aspx
Membership and authentication is one of the basic needs of every Web-Application and among all feature that .net Framework has provided , ASP.NET Membership is one of greatest one that most of developers founded it useful . If you want you can implement your own Authorization and authentication But recommended to use Authentication and Authorization in ASP.NET
you probably need to implement Authorization mechanism for your application
Here is a Built-in Infrastructure provided by Asp.Net
User-Based Authorization
For second Question, the best way is to use cookies. have a look at this tutorial
Read, Write, and Delete Cookies in
ASP.NET