ASP.Net Web Forms Entity Level Access Control - asp.net

I have an ASP.Net Web Forms application in which I'm using forms-based authentication with Membership and Role providers, which is fine for authenticating and controlling access to directories and/or files. Now I find myself needing to control read, write and delete access on individual entity instances, for example being able to update or delete an instance of a customer. I've been trying to think of a good way to implement this but I don't really know where to start. I read about the Authorize attribute in ASP.Net MVC and thought it would be nice to have something analogous--decorating methods the way you can controller actions in ASP.Net MVC. I don't know of any out of the box way to accomplish this in the Web Forms world though, and don't know of any frameworks or other tools that might help me move in that direction. Any suggestions, both in terms of existing solutions and/or how to design my own implementation would be greatly appreciated.

The easiest way is to demand that the user is a member of the role(s) required for the method in question with PrincipalPermissionAttribute.
[PrincipalPermission(SecurityAction.Demand, Role="Supervisor")]
[PrincipalPermission(SecurityAction.Demand, Role="Owner")]
public void DeleteSomething() {...}
Note that this means Supervisor OR Owner can DeleteSomething().

I don't think "PrincipalPermission" is a good approch.
What If, I need to allow DeleteSomthing() for another role?
similarly, If I need to remove existing role for DeleteSomthing()?
The only way is changing the attributes at code level. This is not at all feasible for big projects.
I am also looking for a nice solution.

Related

How to Implement Individual Accounts without Registration in ASP.Net MVC

I'm wanting to test ASP.NET MVC for a new project. One of the requirements is not allowing users to register themselves. When I select individual accounts in the MVC project type, it does not allow for the elimination of the registration option.
Is it possible to create an individual account project without the user registration portion? Do I need to roll my own custom classes? If so, what? I've looked for similar answers, but cannot find any without an already deep discussion and assumption that I am already familiar with libraries involved.
Thank you for any help.

Alternative approach to user management in asp.net web application

I am using asp.net 2.0. I have been using asp.net membership provider for user management. But I think this would be more efficient if I could do this without using role and membership provider provided in asp.net. In fact I see bulky markups generated when I add login control,
createuser control etc. in an asp.net web page.
By saying user management, I am referring to the overall login, user activity tracking, password reset/retrieval, role management in an asp.net web application. And I want to implement efficient way to accomplish this.
Any suggestion would be appreciated.
What exactly bothers you? Server-side code, or the HTML which gets served to the client?
If former, then you can implement your own providers or just reinvent the whole system from scratch (which I do not recommend, but it might be worth it in some scenarios).
If latter, just write your own set of controls that use Membership API.
As far as "efficiency" is concerned, you're not clear in what "efficient" means to you.
Most (all?) of the membership controls support templates, which means you can customize the markup they generate to the client.
See this tutorial to get you started: A Crash Course on ASP.NET Control Development: Template Properties
As for the database hits, I don't think it's a huge problem, but if you're concerned I'd suggest load testing it to make sure. Also, if you set CacheRolesInCookie to true, you can eliminate some of those database calls.

ASP.Net Security: Wrap Requests in IHttpHandler or use RoleProvider?

I'm working with ASP.Net MVC as well as DynamicData and I need to add role-based security.
Should I implement this via:
IHttpHandler with custom actions that check if the user is authorized?
Or should I be using a RoleProvider?
Or perhaps some combination of the two?
If the RoleProvider is a viable option, when would I ever need to extend the abstract RoleProvider base class vs. using the ones included. MSDN says you would only extend this class if "You need to store role information in a data source that is not supported by the role providers included with the .NET Framework." Please expound on this. Explain how this would work under circumstances where I don't need to extend the base class but instead use the included role providers. What data sources are supported by the included providers?
Also, would your answer to these questions be different for ASP.Net MVC vs. ASP.Net DynamicData?
All MSDN is saying here is "we wrote this stuff for you, tested and debugged it, please use it".
The default role providers work great if you spend some time to set them up. Implementing your own isn't too hard either.
I'd answer both pretty much the same. With MVC your setting an Authorize attributes on your Controller and/or Controller actions. With Dynamic data your setting things up with inside the web.config file.

Forms authentication List ApplicationNames

Setup:
Multiple web servers with synchronized
forms authentication.
Multiple asp.net Applications running on these severs.
What's working:
SSO across all servers
Authorization using asp.net roles
What's not so good:
All roles are "global" - I have "admin-app1" and "admin-app2" etc.
Question:
I know this can be solved by defining different "ApplicationNames" for each of the different applications but what is the most easy way to compile a list of all the different applications a logged on user has a role in?
I would like to do something similar to: CurrentUser.Applications()
to get a list of "all applications in which the current user has any role".
Up to now I have used Roles.GetRolesForUser() to compile the list not very elegant or scalable.
Using the SqlRoleProvider I can hack inte the DB to get the complete list of Applications and then compile an application list for the user by query the different application's role providers. My best shot so far but it doesn't feel like the best solution...
Any hints or comments?
BR, Jens
I have come to the conclusion that this cannot be done using the framework.
Anyone who tries to do something similar e.g. buiding a dashboard of all asp.net applications hosted has either to maintain the list of applications separately or hack into the sql tables if you are using the SqlRoleProvider .
Happy hacking!
/Jens
I think ApplicationName is for completely separating applications while using the same database. Are you sure you can link users in one application name to roles in another?
Your best bet is probably to keep the same application name and implement a custom role provider.
http://msdn.microsoft.com/en-us/library/8fw7xh74.aspx

ASP .NET authentication against Active Directory and Roles via ASP.NET role provider

In my current project, we need to authenticate users of an ASP.NET application against Active Directory. I think it can be achieved using the membership provider without too much problems. but we need also to manage user roles that will be kept in the ASP roles management tool.
Did anyone implement this configuration? Does it look feasible?
Any tip for one or the other point?
Thanks.
David
Yes! The ASP.NET role provider is designed to work exactly in that case - the particulars of the authentication provider are irrelevant to the role provider, and it will store the bare essential information to make the two work together - basically the user's AD identity (domain\user) is tracked in the role database and matched up when necessary.
There is an ActiveDirectoryMembershipProvider that can be used to use Active Directory for authenticating users.
Alternatively, you could roll your own MembershipProvider by extending the abstract MembershipProvider class and then use System.DirectoryServices to check against Active Directory when validating a user (ValidateUser method of MembershipProvider). This is pretty straightforward to do and you need only implement the methods that you actually need in the custom provider.
You might consider implementing your own RoleProvider too, depending on whether the default fits your needs.
Use it all the time, intranet only of course.
You may be interested in the WindowsTokenCachingRoleProvider. In scenarios where performance is essential, this really shines:
http://lvildosola.blogspot.com/2007/02/improve-performance-when-using.html
Simple and elegant.
Please take a look at this question, seems like you're asking for pretty much the same thing, and my answer there should give you what you need.
ASP.NET Membership and Role providers that can be used from ASP.NET and WinForms/WPF clients as needed.

Resources