Best free way to use AOP style MVC-like authorizat

Question

I like the authorization attribute in ASP.NET MVC. Not so much the attribute itself, but the way you apply it.

I want to use it in my non-ASP MVC services layer preferably in my plain C# business logic library or at least but less preferably at the endpoints of my WCF service endpoints. Is PostSharp my only answer or is there a free similar solution?

Answer 1

PrincipalPermissionAttribute is about as close as it gets to ASP.NET MVC's own AuthorizationAttribute. You use it the same way, except you decorate methods instead of actions. It allows you to demand access by user role, by user name, or simply by whether she has authenticated or not:

User belongs to Administrators role:

[PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]
public void YourMethod()
{
    // do something
}

User name is john:

[PrincipalPermission(SecurityAction.Demand, Name = "john")]
public void YourMethod()
{
    // do something
}

User is authenticated:

[PrincipalPermission(SecurityAction.Demand, Authenticated = true)]
public void YourMethod()
{
    // do something
}

These throw System.Security.SecurityException when Thread.CurrentPrincipal does not match your access specification.

Answer 2

I am in a similar situation and have recently researched quite a few options.

There are a few open source projects for AOP with .NET but most seems to be abandoned or not very active. PostSharp is by far the most mature of them. There is a community edition which is free and can be used for commercial development.

Other static weavers (such as PostSharp):

• AspectDNG (abandoned)
• Gripper-LOOM (not updated since 2008)
• AOP.NET (seems to be abandoned)

The other option would be to used Dynamic Proxies instead. There are a few libraries which uses this technique but with the exception of Spring.NET they seem to be more or less dead as well.

• Spring.NET AOP (http://www.springframework.net/doc/reference/html/aop-quickstart.html)
• AspectSharp
• Rapier-LOOM.NET

I believe Spring.NET AOP can be used without the rest of the Spring.NET stack but I'm not entirely sure.

If you don't mind to work on a lower level there are always Mono.Cecil which allows you to rewrite assemblies just like PostSharp does but I wouldn't recommend it. It will be a lot of work and hard to get right.

Generating dynamic proxies with for example Castle.DynamicProxy or LinFu is probably a better approach then but it will still be quite a lot of plumbing to make everything to work. Also, unless you are already using an IoC-container you might want to consider that as it will make it much easier to inject the proxies where needed. Compared to using an OnMethodInvocationAspect or similar from PostSharp it will be a lot more work.

I currently leaning towards using PostSharp (Community Edition) since it does everything I need and is very easy to use. Spring.NET seems somewhat interesting but a dynamic proxy based solution won't be quite as elegant or easy to use as PostSharp.

Answer 3

Microsoft's Unity provides the ability to write AOP code through method interception. If your interception methods examined the attributes on the intercepted method you should be able to do precisely what you want.

You can read about Unity interception here

Answer 4

There's a few solutions out there -- here's a list of open source and commercial products. The only one that doesn't seem to exist anymore is AspectSharp - that link is broken. Most of these don't seem to have been updated in a year or so, but it could be a start. PostSharp is also on the list.

Hope this helps.

Answer 5

NDecision makes decision-tree business logic quite simple to implement, and if you're a fan of Gherkin syntax and Fluent coding practices you'll feel right at home using it. The code snapshot below is from the project site, and demonstrates how business logic could be implemented. NDecision.Aspects is the AOP layer on top of NDecision. NDecision.Aspects makes use of PostSharp attributes, in fact, and dynamically intercepts code execution to apply business rules on the objects being passed as parameters (or the objects that own the methods being executed).

The code in the following screenshot demonstrates how you would write your business logic in a separate class:

Then you activate the autonomous application of the specifications (the business rules) using one of the NDecision.Aspects attributes:

Or by applying the attributes to the method on the target type to which your specifications apply:

There's no reason why you can't have another assembly with your "decision tree." NDecision was written with that in mind, to separate the logic into one independent layer, and the NDecision.Aspects portion allows for the application of these rules wherever you need.