Custom code access permissions

We have a server written in C# (Framework 3.5 SP1). Customers write client applications using our server API. Recently, we created several levels of license schemes like Basic, Intermediate and All. If you have Basic license then you can call few methods on our API. Similarly if you have Intermediate you get some extra methods to call and if you have All then you can call all the methods.

When server starts it gets the license type. Now in each method I have to check the type of license and decide whether to proceed further with the function or return.

For example, a method InterMediateMethod() can only be used by Intermediate License and All license. So I have to something like this.

public void Inte开发者_开发百科rMediateMethod()
{
   if(licenseType == "Basic")
    {
         throw new Exception("Access denied");
    }
}

It looks like to me that it is very lame approach. Is there any better way to do this? Is there any declarative way to do this by defining some custom attributes? I looked at creating a custom CodeAccessSecurityAttribute but did not get a good success.

Since you are adding the "if" logic in every method (and god knows what else), you might find it easier to use PostSharp (AOP framework) to achieve the same, but personally, I don't like either of the approaches...

I think it would be much cleaner if you'd maintained three different branches (source code) for each license, which may add a little bit of overhead in terms of maintenance (maybe not), but at least keep it clean and simple.

I'm also interested what others have to say about it.

Good post, I like it...

Possibly one easy and clean approach would be to add a proxy API that duplicates all your API methods and exposes them to the client. When called, the proxy would either forward the call to your real method, or return a "not licensed" error. The proxies could be built into three separate (basic, intermediate, all) classes, and your server would create instances of the approprate proxy for your client's licence. This has the advantage of having minimal performance overhead (because you only check the licence once). You may not even need to use a proxy for the "all" level, so it'll get maximum performance. It may be hard to slip this in depending on your existing design though.

Another possibility may be to redesign and break up your APIs into basic/intermediate/all "sections", and put them in separate assemblies, so the entire assembly can be enabled/disabled by the licence, and attempting to call an unlicensed method can just return a "method not found" error (e.g. a TypeLoadException will occur automatically if you simply haven't loaded the needed assembly). This will make it much easier to test and maintain, and again avoids checking at the per-method level.

If you can't do this, at least try to use a more centralised system than an "if" statement hand-written into every method.

Examples (which may or may not be compatible with your existing design) would include:

• Add a custom attribute to each method and have the server dispatch code check this attribute using reflection before it passes the call into the method.

• Add a custom attribute to mark the method, and use PostSharp to inject a standard bit of code into the method that will read and test the attribute against the licence.

• Use PostSharp to add code to test the licence, but put the licence details for each method in a more data driven system (e.g. use an XML file rather than attributes to describe the method permissions). This will allow you to easily change the licensing across the entire server by editing a single file, and allow you to easily add whole new levels or types of licences in future.

Hope that gives you some ideas.

You might really want to consider buying a licensing solution rather than rolling your own. We use Desaware and are pretty happy with it.

Doing licensing at the method level is going to take you into a world of hurt. Maintenance on that would be a nightmare, and it won't scale at all.

You should really look at componentizing your product. Your code should roughly fall into "features", which can be bundled into "components". The trick is to make each component do a license check, and have a licensing solution that knows if a license includes a component.

Components for our products are generally on the assembly level, but for our web products they can get down to the ASP.Net server control level.

I wonder how the people are licensing the SOA services. They can be licensed per service or per end point.

That can be very hard to maintain.
You can try with using strategy pattern.
This can be your starting point.

I agree with the answer from @Ostati that you should keep 3 branches of your code.

What I would further expand on that is then I would expose 3 different services (preferably WCF services) and issue certificates that grant access to the specific service. That way if anyone tried to access the higher level functionality they would just not be able to access the service period.