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.
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
Currently using DNN 5.2.x and we are using only 1 portal on the site. We need to make a mobile version of the portal and eliminate most of the extra DNN stuff as info will be just displayed. So what we decided to do was create seperate ASP.NET Web Forms website and utilize the DNN providers (membership, roles, etc) to do the logging in. However we are currently having issues. The one in particular is ("unknown exception trying to write to log"). We've moved most of the DNN Global.asax (i.e. SimpleContainer instructions) file to the new website and added the necessary web.config sections and references however we get this error when a user logs in. We did copy over the same web.config machine key to the new website. The connection strings are also there (app settings and connection string sections and is named SiteSqlServer).
So my question is, has anyone created a new website around DNN without using DNN except for the membership? i.e. no modules, no skins, etc. Just validate user and get roles.
If you have what needs to be done to get DNN 5.2.x (or later) to log a user in and return the roles, could you post your steps?
The default DNN login is based on ASP.NET membership. If all you really want is the login feature, it will be MUCH MUCH easier to simply use the ASP.NET membership directly than try to rip it out of DNN.
What you are trying is not impossible, but certainly will require substantial patience with trial and error.
For only validation users and getting roles you could write your own simple providers that utilize dnn special tables in the databse like (Users, Roles, UserRoles, Profile etc). The table User is associated with the aspnet_Membership and aspnet_Users standard tables via the Username field.
There are many options which are open for you.
If you really don't want to digg into complecations of how to integrate the dnn membership and role provider will work, you can check dnn single sign on
Another option is to have your webforms application as a subfolder in your dnn website. that way you don't have to do much effort and you will have all the good things ready to get started. even you can directly convert your skin to master page and reuse almost all the css and image related suff
In addition to above, I also suggest another smart way to do this. Since you are considering a mobile site, why don't you try and detect the browser using Request.Browser and create a separate skin for dnn that is of smaller size. We can easily switch skins dynamically for service requests.
I hope this will help. If you have more questions regarding this, I will be happy to help. Just drop me and email and I will try to help you get as close as possible to get you going.
Good Luck
This is the route we took. We basically implemented DNN in the mobile version of the website. Except we only utilized the User Membership features of DNN. To do this we had to use all the same core DNN dll's and also include all the "bootup" features in the global.asax file. We also had to on every request inject a UserInfo object into the session context. I forget the key name for the UserInfo oject used but it is used by DNN and must be set in a DNN handler that we did not incorporate. Other than that it works perfectly. We have the ability to get all the roles a user is in and etc.
Is it a good design to have multiple masterpages in an application.
I am building a website using Asp.net MVC with different type of users like, admin, employee, general user, etc
And every user once logged in have different type of controls on the website, so I was planning to use different master page for each user.
Yes it is a good design, and make sure to layer them appropriately. Master pages specific to controllers should be placed them in the appropriate view folder.
If it makes life easier for you and your users, than I see no reason why not.
I don't know how about Asp.net MVC, but in Asp.net master pages inheritance is possible. You may create site.master, and admin.master, employee.master, etc that all inherit from site.master.
But take care of master pages inheritance. In my project, it seems that sometimes paths may point to wrong locations. I don't know whether it is my mistake or is a bug.
I was wondering if it is possible to do a RedirectToProvider and have the resulting OpenID provider page displayed in an iFrame. This would make the authentication flow seem a lot more streamlined.
I am using the DotNetOpenID library in ASP.NET MVC (VB).
This next part is sort of a seperate question, but is related.
I am using Ajax.BeginForm for the OpenID sign in form, however the RedirectToProvider fails here for some reason. Does DotNetOpenId not work with MVC and AJAX?
Yes, DotNetOpenId supports iframes, MVC and Ajax. The OpenIdAjaxTextBox control that ships with the library and is shown used in one of the samples demonstrates this. It does not use iframes to display anything. It uses them with checkid_immediate to attempt implicit login without any user interaction, which is the only iframe-scenario that OpenID intends to support.
The IAuthenticationRequest.RedirectToProvider method internally invokes the ASP.NET Response.Redirect, which itself throws a ThreadAbortException, which might be why it seems to be failing for you, when in fact it's probably working by design, but that design conflicts with what you're probably trying to do.
There are various approaches to take to get what you want done, but as Workshop Alex has already suggested, there is a security concern with hosting the Provider's page in an iframe. It's not that the RP can access or mettle with the content of the iframe, because as EFraim said unless the browser has bugs that would not be allowed anyway. The two problems with it are Clickjacking and that you're training the user to be phished, since he will likely be providing his login credentials to his OP while the RP's URL is in the location bar, which is a bad thing.
And in fact, major OPs now deliberately refuse to work when they are activated within an iframe, so after the work to get it all to behave the way you want, you'd likely be disappointed that most of your customers won't be able to login.
Also as you point out, popup windows, when done properly, can help keep the experience user friendly. You can achieve this a few different ways with DotNetOpenId as well. The ASP.NET controls that come with the library have this feature built in and can be activated by just setting a property on the control. But since you're using ASP.NET MVC (I think), here's how you can do it yourself:
When the user clicks the Login button on your page, rather than POSTing to the current window, have Javascript that opens an appropriately sized popup window at a URL like http://yoursite.com/openid/redirect?id=userSuppliedIdentifier.
Your OpenID controller's Redirect action will read that ID, do an OpenIdRelyingParty.CreateRequest on that ID, and return IAuthenticationRequest.RedirectingResponse.AsActionResult() (MVC style). Note you can pass your own URL to CreateRequest for a returnTo url if you want the OP's response to come back to a different method on your OpenID controller.
When the assertion comes back, your controller should send down javascript that closes the popup window and (as necessary) communicates back to the main window to update its state for the logged in user.
This whole process is completely automated in the ASP.NET controls that DotNetOpenId ships with. It's unfortunate that ASP.NET MVC cannot be made as modularized as ASP.NET web forms so that you don't have to do all this work yourself. Of course, the MVC sample that DotNetOpenId ships with could be made to show how to do popup behavior in a future version. If you want that, file a wish for it.
Question is, would the OpenID provider consider this a security risk or not? If the provider page is inside an IFrame then the surrounding page can have some control over what's happening inside this frame, including an attempt to capture some of the information. It could be a possible exploit risk. Do keep in mind that OpenID providers are very paranoid about these things and might even attempt to break out from such an IFrame or just deny any further login actions. It's a risk that they might not want to take.
Is it possible? If it is, I think the answer also depends on the provider.
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.