ASP.NET Membership and Role Based Support

Question

I am developing a blog engine with ASP.NET & C# . The main solution consists of several projects listed below.

• DomainModel : domain objects and interfaces for repositories
• AppService : application services, viewing model maps, messages, etc.
• Repositories : Repositories EF, XML Repository, Stub Repository
• Presentation : implements the MVP template (presentations, speakers, interfaces)

The user project is currently a WebForms web application, and the project is almost complete. The last thing to do is integrate the entire system with ASP.NET Membership . There are two things to consider.

First, only the user account ID is required from the blog database of the blog database. And finally, role protection must be implemented in the user interface design. Since I'm fairly new to the development of distributed applications, DDD and more, I wanted to know whether role-based security is simply the responsibility of the user interface application, or if there are other issues that need to be taken care of in different layers of the solution. As far as I know, only views (web pages) should implement role-based security, display different content, and offer different functionality depending on the current session. but is that all?

I know that this can be a general question, of course, implementation and design will vary depending on the needs of the project. but if there are general rules of thumb to follow when implementing role-based security and form-based authentication in a distributed / tiered application, it would be great to know them in advance. eg:

• Is the security implementation simply the responsibility of the user interface application?
• Can I customize / change the design of my domain model and / or other levels so that the role-based security implementation is simpler and does not fall entirely on the user interface application.
• Is it a good idea to consider security at other levels so that the user interface layer is just a representation of the data and the environment between the user and the system.

Answer 1

Security is a cross-cutting issue: the user interface, application, and domain interfaces are involved. I understand that you are dealing with rules such as "Only the author can edit the blog" or "Only registered users can comment." In this case, the user interface must know these rules in order to decide whether to display Modify or Comment links. Domain objects must enforce these rules.

As far as I know, ASP.NET membership has many functions, including user storage, authentication, authorization, and role management. However, he does not know your domain. He does not know what a blog is. He knows what an ASP page is. Therefore, if you do not want to express your domain rules as page access rules, you can draw a thick line between your application and ASP.NET membership. You might want to delegate user storage and authentication to ASP.NET, but the rest yourself. It might also be a good idea not to have a direct dependency on ASP.NET in your domain module. You also want to consider how ASP.NET membership will work if you later decide to switch from web forms to MVC or if you have a web API for your blogging engine.

Answer 2

Security should be responsible for the entire application. It really depends on how your application is structured.

My opinion is that all levels should have some participation. Security should be another service that other services can use. This way you can access the security model at all levels. The administrator user interface can immediately block the user if he is not authorized, but say that the data search service can check which objects he is looking for are valid for the current user.

You also get benefits this way if you want to use your data model in other ways, for example, through web services or from some other application, for example Silverlight.

Update

All levels really need to be aware of security, as all levels must touch it at some point. The user interface of this requires that it can enable and disable user interface elements. Services should be aware of this to ensure that the actions they perform are valid for the current user, etc.

Security really should not be what you think at the end of the project and just turn on. it must be something designed for the application at all levels.

How you implement it will depend on how you wrote your application. I would say the best way is to have an abstraction layer between your application and asp membership. You get all the benefits that you already know, such as testing, re-archiving, etc.

One of the things you might think about is the concept of rights or permissions. ASP does not have its own libraries to work with this, so you have to collapse your own. At any time, when you want to do something, you check that the user has the right. These rights can be included in roles, which, in turn, can be assigned to users or user groups. You get fine control over what users can do, and this makes it easy to add new roles in the future.

Answer 3

I’m not sure what exactly after this, but it is worth noting the standard PrincipalPermissionAttribute Class works fine with ASP.NET roles implemented using this provider technology.

This means that you can use Code Access Security and declarative attributes to ensure that your API / Domain / Methods can only be accessed by users in a specific role. So yes, you can provide security outside of the user interface layers using ASP.NET membership.

Answer 4

For some time around this problem, I came to the following conclusion.

Security implementation like Authentication , Role-based security , Authorization , etc. At the user experience level, it is not a good idea mainly for two reasons:

• If you want to create other user interfaces for your application, say, WinForms or Silverlight , you will have to implement this protection again from scratch.
• You can always use other components / levels of your system without creating a user interface. Suppose you are creating a simple console application that references other levels on your system (i.e. Repositories ). then you can instantiate the repository and manage the data. in this case, you have successfully redefined any security.

Thus, the solution is to implement this in-house security at a different level, built into the domain model itself and not tied to a user interface (UI).

Now there are several options for how you can do this. let's say we have a layer called AppService , which is the entry point to the whole system. this layer consists of messages (a messaging template, for example, a Request-Response template), ViewModels , which are flattened views of domain objects and Methods for retrieving and manipulating data , etc., here we can implement such security measures using PrincipalPermission objects. we can apply security rules to classes and methods. here is a simple example:

 [PrincipalPermission(SecurityAction.Demand, Authenticated=true)] public void DoSomething() { } 

With the attribute defined for this method, the code requires that the caller be authenticated. authentication model can be any, including Windows Authentication , Forms Authentication and so on. Now this works fine, because now we have loosely coupled the user interface with the security rules defined at the service level. however, there is still a catch.

This design will work fine, since the service level is indeed the main entry point for the system. that if you can still instantiate, say, in the repository, without having to get an instance of your AppService, you can still override the security rules. that, as they say, you should design your domain model in such a way that an instance of AppService is required to work with the components / levels of your system. in this case, any function provided in the system is available only through the application service level. on the other hand, if this is not possible or does not bother at the moment, you will also have to define your security rules in other layers. which means that you also have to define security rules in your repositories. so if someone creates an instance of the repository and tries to manipulate the data without executing his commands through the UI or AppService , you still apply security measures.

Another thing is that using PrincipalPermission rules for your classes and methods is not tied to a specific authentication / authorization model. therefore, you can use such security rules in web applications using Forms Authentication or Windows applications using Windows/AcctiveDirectory Authentication , etc.

As you remember, I am developing a simple blogging engine in ASP.NET , and this model is working fine at the moment. if there are more detailed in-depth pros and cons, or samples and blog posts that may help in this section, be sure to post your comments and answers [: