We need to replace the menu system in our main ASP.NET application. So naturally we're looking at the ASP.NET SiteMapProvider and Menu controls. However we also need enough security to prevent users from directly entering URLs that they shouldn't have access to. We can do this by putting <location> entries in web.config and securing them individually but that's going to be a PITA to manage across multiple web servers.
Is there a Provider that can be used to, well, provide the equivalent of the <location> entries? I haven't been able to find one, and it's slightly frustrating given the existence of the ConfigurationLocation class.
Alternatively is there a configuration option we're missing in SiteMapProvider that will restrict users from getting to URLs they shouldn't?
Why don't you create rights & profiles to manage wich pages a user can see?
I usually create a user class which implements the IPrincipal security interface. On every request to your application, you check the rights of a particular user and output the SiteMap's nodes allowed for this user.
Related
I am failing to find good examples of user and activity based authorization for my ASP.NET web forms site. Currently, i am using user roles in web config to allow/deny access to pages within folders. But this method is proving to be a nightmare to maintain, especially when users come up with special case scenarios, which completely deviate from existing role permissions.
So i am looking for a way to be able to store and retrieve user access rights, from the database and then enforce them on my web site dynamically.
My Second problem is how to show/hide certain site master html from certain users. I was also thinking to store this information in the database, so that these rights are dynamically allocated also.
Currently, i am hard coding in my site master code behind the hide/show permissions by saying:
If(isInRole("Admin"){
// Show Everything
}
else
{
// hide certain html
}
So this approach works currently, but is problematic to maintain and not very flexible.
Finally, I was looking at activity based authorization, the pros and cons of which were well described in this article: http://ryankirkman.com/2013/01/31/activity-based-authorization.html.
So how would i implement that in my ASP.NET web forms site?
In conclusion there is three things i am after:
Dynamically Control Visibility of HTML elements in my site master page based on user authorization.
Dynamically control user authorization to my aspx pages
Dynamically control user activity based authorization
Any input on this would be highly appreciated. Thank you
You should switch from role based authentication to claims based authentication. Here's an article describing the basics of claims based authentication:
http://dotnetcodr.com/2013/02/11/introduction-to-claims-based-security-in-net4-5-with-c-part-1/
Claims will give you fine grained control over the rights for each individual user. ClaimsPrincipal can also be used in webforms:
https://visualstudiomagazine.com/articles/2013/09/01/going-beyond-usernames-and-roles.aspx
An attribute can be applied to pages and methods in an ASP.NET Web Forms application (described in the article above):
[ClaimsPrincipalPermission(SecurityAction.Demand,
Operation="Update", Resource="Customer")]
public partial class CustomerUpdate : System.Web.UI.Page
{
Check this link Authorization Based on User
Or Another thing you can do is, separation of Concern according to Roles
Keep the Views According to the Access Level and Roles, so that you can easily manage the access.
Another thing that I've Seen people doing is Having a DB table with all Roles/Users and Access Links
I have many pages in web application, i want display some pages to all including anonymous user and some pages should be protected from anonymous user can it is possible through authentication and authorization.. if it is possible then please tell me how......
There is built in functionality in ASP.NET for this. See ASP.NET Authorization on MSDN for an introduction.
You can specify what roles are allowed to access different pages/paths. With a membership and role provider you get a built in handling of users and roles. If you are in a corporate environment you probably want to integrate with Windows authentication, otherwise there is a good SqlMembership provider that handles all the user storage in the database in a secure way.
If you want to keep away from building an authentication system into your application you're best bet is to look at putting the pages that need protection into a separate directory on the webserver, then using : http://httpd.apache.org/docs/2.0/howto/auth.html to protect them.
This of course assumes you're using apache.
It is no longer recommended to use the .htaccess files.
Currently, we have a site where almost all the pages fall into some page class that's a subclass System.Web.UI.Page. Generally the subclasses control styling -- headers, footers, etc. -- things displayed on that class of page that we want for all classes.
For one particular class, we check some session variables to see if the user has access to that particular page. If not, they get redirected off and told they don't have access.
I've since implemented a custom role provider and am in the process of updating all my web.config files from to .
The question has arisen: Why not implement the page-based restrictions in the page class instead of implementing a role-provider methodology.
Honestly, when I first considered this topic, it seemed to me there was a clash between and having page classes do the authorization. However, I'm having a difficult time coming up with reasons why page-class based authorization would be a bad idea right now.
If you're able to understand what I'm talking about where we set access (authorization) info during the login process and then use this (session based) information to "authorize" a user to access a page based on the page-class vs using the built-in ASP .NET role provider methodology, I'd appreciate your thoughts on this matter. Especially if you have experience in this area.
Thanks.
Well both ways are possible, IMHO, it comes down to whether you want to use the ASP.NET authorization scheme (allows, denies in the web.config) or code it into the page.
Personally I prefer the configuration approach, as it is more flexible and allows for the pages to inherit from another page class, or use master pages to provide for a common look and feel.
Suppose I have 3 kinds of users and their accessible pages in my ASP.net application are as follows:
(1) User Type-A {Default.aspx, a.aspx, b.aspx and c.aspx},
(2) User Type-B {Default.aspx, d.aspx, e.aspx and f.aspx},
(4) Admin {Default.aspx and g.aspx}.
Here Default.aspx is my Login-page.
I am using Membership Provider and Forms authentication technique.
Now I need to block access of one type of user to the pages assigned for other type users.
How should I configure my Web.config file?
and What kind of c# code should be used?
Role management in asp.net may help you in this case. Please check this article.
You may have to customize this as per your specific requirement. Hope this helps.
Role Manager in ASP.NET
Each of User-Type will be associated with Roles.
We have a similar requirement, and make use of the Patterns and Practices Web Client Software Factory. Basically it assists you in creating modules, and allowing you to specify per-page access levels in config based on Role / User details.
You might have a try to use roleship provider and web.sitemap.
I have an application that uses Forms Authentication to authenticate one type of user. There is a section in this application that needs to be authenticated for another type of user using a different table in the database. The problem happens if the second type of user's session times out, she is taken to the login page defined in the Forms Authentication section of the main Web.Config instead of the login page for the second type of user. I am looking for solutions to this problem. One idea is to create an application in IIS for the section and create a Web.Config for the folder and add another Forms Authentication section. In my experiments, it seems this doesn't work. Am I missing something obvious? Any insights?
IIRC, the authentication works per folder. So you should be able to do it if all of the pages that require the 2nd type of authentication live in a specific sub-folder with it's own config.
Not 100% sure on this, though, so if someone more knowledgeable can contradict me I'll just delete the response.
You may need to double check me on the syntax, but the top level web.config can have any number of tags.
<location>...</location>
Inside you can specify separate config parameters for whatever folder/file you want. Look here for a reference.
EDIT: Apoligies, I neglected to format the code properly
You cannot have an <authentication> section inside of a <location> tag, so you must have the subfolder set up as an IIS (and ASP.NET) application of it's own. So, you should be able to run the subsection on it's own.
I think 500.19 is the "can't read or parse web.config" error - does it have details? You may need to turn on remote errors (or check Event Viewer) to see them. If you're still having issues, post a snippet of web.config.
As an aside - I've never been a fan of nested apps, and would probably prefer having your normal Login.aspx page handle it either with as a MemberOf or perhaps redirecting to a SpecialUserLogin.aspx or something. Nested apps are a PITA to setup and test, IME (for instance - I don't think you can even get it working under Cassini - though you can do 2 separate projects for it, and combine when you deploy).
Yes you can. The Web.config files have a tree-like inheriting arhitecture with override capabilities. Meaning you can modify the settings inside a sub-folder by placing a web.config file there and specifying different configuration settings.
The way I understand this problem, you have two solutions and the first is to look at Roles and the whole Provider Model would be a great place to start. Otherwise, the best bet would be to separate the application into two parts, breaking out the second user type area and then including it back into the main project via a Virtual Directory. Just remember that Virtual Directories inherit their permissions from the parent directories web.config, so you will need to use the <Location>tags to remove authentication for the virtual directory and then within the virtual directories web.config define your new forms authentication. This works well if you need Windows Authentication (NTLM) under Forms Authentication.