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.
Related
I'm implementing a Custom RoleProvider in the .NET Membership-framework. The existing functionally needs a little tweaking, so I want to implemenet my own Public Functions, to invoke around the static Roles-class.
Instead of Object -> Roles -> RolesProvider
I would go Object -> RolesProvider
Would this be considered bad practice? The only alternative with the current databasescheme is to ommit the use of RoleProvider totally, and implement my own custom system for authorization.
Edit: To clarify, I have already implemented a custom MembershipProvider, so the desire to keep working in the Membership-framework is pretty high.
Any time you circumvent part of a framework or customize it in a way that was not intended it could be considered bad practice. It is the intention of the ASP.NET membership provider framework to facilitate access to the current provider through the Roles class.
The danger of 'bending' the framework to suit your needs instead of extending it as intended is this: there may be other areas in the .net framework, configuration or tools around the role membership functionality that make this assumption, and they may no longer make sense after your changes and cause confusion for others involved in your project. The ASP.NET Website Administration Tool is one example of a tool that makes this assumption. If someone were to use this tool after your changes, your role memberships and site could be potentially corrupted as a result.
If you decide to take this approach you should carefully consider what functionality you are adding and ultimately ask yourself it is really necessary. If it is, you may be better off implementing something completely custom instead to avoid confusion.
Do I need to implement all the required methods on the MembershipProvider and RoleProvider if writing a custom one to use the AuthorizedAttribute in ASP.NET MVC?
There are a few features that I don't want to implement like CreateUser or 'DeleteRole` because they violate the system I will be authorizing/authenticating against.
No, you don't need to implement everything if you never use this functionality. Throwing a NotImplementedException is always a good way to indicate this.
I am currently doing the same thing and you don't have to implement all the methods.
You might want to look at the following website.
http://theintegrity.co.uk/2010/11/asp-net-mvc-2-custom-membership-provider-tutorial-part-1/
Great tutorial for implementing a custom membership provider with ASP.NET MVC!
No you don't need to implement all methods for the MembershipProvider or RoleProvider; if you never use the API for creating, updating, or deleting, then you could throw an exception when used. These are there in case you do modify user data, and are also used by the Administration web site option in Visual Studio. So if you use that web site, it quite won't work as expected as it expects these provider methods to be present.
But if all you do is use the controls, then it would be handy to research which API methods these control use and make sure that you have implementations for those. What I mean is that Login control uses ValidateUser for sure, and may use GetUser too. It may also call UpdateUser to update the failed logon count, last login date, etc.
HTH.
Looking to implement authentication/authorisation for ASP.NET app
Was looking into using Provider model MembershipProvider SQLServerMembershipProvider etc as makes good sense to me.
However I'm looking into the Enterprise Security Application block as well. My question is can/should the two be used in tandem?
Yes, these two components would play together nicely. In fact, one is built upon the other.
The more important question is, do you need both for your particular scenario? Look at what the MembershipProvider functionality gives you out of the box. What is it that the EntLib Security Block adds to this that is necessary for your application?
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.
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.