ASP.NET Membership & Role-based Security

Question

I'm developing a blogging engine with ASP.NET & C#. the main solution consists of several projects as listed below

• DomainModel : domain entities and interfaces for repositories
• AppService : application services, view model mappers, messages, etc.
• Repositories : EF Repository, XML Repository, Stub Repository
• Presentation : implements the MVP pattern (views, presenters, interfaces)

The user-end project is a WebForms web application for now, and the project is almost finished. the final thing is to integrate the whole system with ASP.NET Membership. there are two things to consider.

First off, only a user account ID is needed from the membership database in the blog database. And finally the role-based security has to be implemented in the UI project. since I'm fairly new to distributed application development, DDD and stuff, i wanted to know if the implementation of role-based security is merely just the responsibility of the UI app, or there are other things to be taken care of in the other layers of the solution. as far as i know for now, only the views (web pages) have to implement role-based security and render different content and offer different functionality based on the current session. but is that all?

I know this might be a generic question, of course the implementation and design would vary based on project needs. but if there are general rules of thumb to follow when implementing role-based security and forms authentication in a distributed/layered application it would be great to know them before hand. for example:

• Is security implementation just a responsibility of the UI app?
• Can I tweak/change the design of my domain model and/or other layers, so that the implementation of role-based security would be easier, and not fall on the UI app entirely.
• Is it a good idea to take security into account in other layers, so that the UI layer would be just a representation of data and a medium between the user and the system.

Answer 1

Security is a cross-cutting concern: UI, application and domain layers are involved. My understanding is that you deal with rules like "Only Author can edit Blog" or "Only registered Users can comment". In this case UI should be aware of these rules to decide whether to render 'Edit' or 'Comment' links. Domain objects should be able to enforce these rules.

As far as I know ASP.NET Membership does a lot of things including user storage, authentication, authorization and roles management. However it is not aware of your domain. It does not know what Blog is. It knows what ASP Page is. So if you don't want to express your domain rules as page access rules you may want to draw a thick line between your app and ASP.NET Membership. You may want to delegate user storage and authentication to ASP.NET but do the rest yourself. It may also be a good idea to not have 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 will have a web API for your blogging engine.

Answer 2

Not sure what your exactly after, but it's worth to note the standard PrincipalPermissionAttribute Class works fine with ASP.NET roles implemented with this provider technology.

It means you can use Code Access Security, and declarative attributes to ensure your API/Domain/Methods can only be access by users in a specific role. So yes, you can enforce security beyond UI layers using ASP.NET Membership.

Answer 3

Security should be the responsibility of all of the app. It really depends on how your app is structured.

My view is that all tiers should have some involvement. Security should be another service, that the other services can use. That way you can access the security model at all levels. The admin UI can block the user immediately if they're not authorised, but say the data retrieval service can check the objects it's retrieving are valid for the current user.

You also get benefits this way if you want to use your data model in other ways, say via web services or from some other app, eg Silverlight.

Update

All tiers really need to be aware of security, as all tiers need to touch it at some point. The UI needs it so it can switch UI elements on and off. Services need to be aware of it to ensure they actions they are executing are valid for the current user & so on.

Security really shouldn't be something you think of at the end of the project & just switch on. it should be something designed into the application at all levels.

How you implement it will depend on how you've written your application. I would say the best way is to have an abstraction layer between your app & asp membership. You get all the benefits you already know, eg testing, re-architecting, etc

One of the thing you might want to think about is the concept of rights or permissions. ASP has no native libraries for dealing with this, so you'd have to roll your own. Anytime you want to do something, you check the user has the right. These rights can be rolled into roles which in turn can be assigned users or groups of users. You get fine-grained control over what users can do & it makes it easy to add new roles in the future.