Hi everyone,

I have been creating Components for ASP .NET and now planning to create a store for them. When I thought the public release of my components, I thought about the security. I have seen many components/applications on the NET who provides strong licensing schemes but as a programmer, I am more interested to create my own.

Here are some thoughts of mine.

I thought to generate some key on the base of User name and/or email and then store that to registry and everytime my component start, I check that string matched and if not, it simply raise an error. But I may face a problem that on some servers, registry access may be denied so this thing may fail.

Secondly I though to create some highly encrypted file where linsenced string is stored, but again most of the time on server, write and read access is denied (through application). this again get failed.

Now I am here to share my thoughts that what should be the best and fool proof way to create licensing scheme so that I can secure my components and can freely place them on my site to download as evaluation or trial version. Since I have ASP .NET components, so I may wish that the users can use them freely on localhost but they must purchase license to run on server.

Any idea or comment will be highly appreciated

---

Sameers (theangrycodeR)
http://www.theangrycoder.com/IamAway.aspx

This is a new area for me but one that I will be facing as I finish my controls. I hope you get some good feedback on this. I thought some about providing a license key in an email to the customer when they register for download. Maybe set up some sort of algorithm that expires it in 30 days. That way they can use the component anywhere they want for 30 days but at the end of 30 days the component will stop working without a new demo key or a permanent key. This sounds like about as secure as you can get... but face it, if someone wants to steal it bad enough there is no way to truly guarantee that they can't, at least not that I know of. I also considered licensing to some customers based on a domain name, but seeing how the target market is developers, and they probably work on several sites throughout the year I sort of put that idea on the back burner.

---

Answering a question increases your knowledge asking a question shows your Intelligence!

AngryCoder, meet the GrumpyCoder :-) . I would store the license key as a signed XML file in the IsolatedStorage. And I would my licensing scheme would check that the license is valid by checking every week (on domain based licenses) with a web service that you can create. Remote activation sounds good.

And knowing that you get angry so quickly :-P , you might want to use either of the products (from other sites):

Xheo Licensing
Open License (apparently, still buggy bu free).

---

-- Justin Lovell

Nice to meet you Grumpy :)

After posting the thread here, I started working on the project and I am almost done with basic things. I have created an application to generate license and a component to ensure that license is good. Thoug basic but not much secured yet.

Well, I also have stored that in XML file with encrypted key inside that. I used RegisteredTo, website and component name to create a unique key. Idea of the webservice is good and I will think to use it.

BTW, I am truely angry and avoid as much as I can to use third party. Very good reason is to increase my knowledge :@ I already have seen Xheo Licensing (downloaded trial version) and I am thankfull to Xheo team who provided me a very good idea to start the job.

---

Sameers (theangrycodeR)
http://www.theangrycoder.com/IamAway.aspx

I?m usually a happy coder. But I too have been looking at adding licensing to some controls I?m working on and I must admit it?s making me grumpy. As much as I?ve grown to love .NET, I find the built in support for licensing lacking.

I think that licensing should be handled by the CLR similar to the way security is implemented. Ideally you could use declarative attributes to specify what type of license a component requires. Obtaining the license would be handled by the CLR. License providers could be configured externally in much the same way that security policies are configured today. It would be really nice to have a licensing manager that could handle all the licensing needs at the Enterprise, Machine, and User level.

Instead the license provider is specified as an attribute which couples the process of obtaining and validating a license to the component which has many disadvantages.

This forces the component developer to develop a rock-solid licensing scheme prior to distributing the component because any changes to the licensing scheme will require the component to be rebuilt.

This forces the application developer to keep track of multiple licensing schemes because there is no standard ASP.NET licensing mechanism. The developer not only needs to learn how to use a control but needs to learn the licensing scheme as well.

Microsoft has posted a sample ASP.NET server licensing implementation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnetcontrollicensing.asp

In this article they list requirements that ASP.NET server licensing should follow. These can be summed up as follows:

1. The licensing scheme should be fool-proof for the developer so they can be confident that there licensing scheme will work and don?t have to spend more time implementing licensing than the control they?re trying to license.
2. The licensing scheme should be fool-proof for the application developer so they don?t spend hours trying to figure out why the control they purchased is throwing licensing exceptions.

That said, I am very wary of any licensing scheme that uses web services to validate licenses at runtime.
1. This adds complexity for the component developer. They now need to implement a web service and a web service client. Any changes to the service would require rebuilding the client.
2. Security: For intranet solutions, firewalls could easily throw a wrench in the web service licensing scheme. Also, there may be ASP.NET security permission issues. If you use a web service definitely use declarative security attributes to demand permission to access the web service URL.
3. Reliability: The web service must be extremely reliable because other sites are depending on it at runtime. This would make some developers wary of using the control.

I think it?s important to remember that most developers will adhere to the licensing agreement if the control is useful and reasonably priced. And there will always be the select few developers that will go to great lengths to try to circumvent any licensing policy.

The trick is offering some protection for your work without jeopardizing the functionality or usability of the control.

I?ll probably use the encrypted license file sample from the article mentioned above. I think I should probably modify it to use asymmetric encryption so the key isn?t embedded in the distributed code.

I think the directory structure required by the sample may be a bit excessive. I may just have the app developer add an encrypted license string to the web.config file. I?m only worried about runtime licensing, not design-time and this is the simplest scheme I can imagine.

---

Brian Price
Co-Author of UCanUse Products
UCanUse.com
Wittysoft, LLC

:: That said, I am very wary of any licensing scheme that uses web services to validate licenses at runtime.

1) Hmmm... it is the same as developing any heavy based web service. Do not move it or do not change the two-way-call method.

2) That is why there will be a thing called "server" licenses. Those licenses are created and activated just like windows 2003 and office 2003. Normally, control vendors do provide the different licensing schemes for situations just like the one that you have mentioned here.

It also works over here for the corporate network (server licenses) because it is cheaper for by-the-domain that the server may host.

3) Not every network is fail-safe. You could have the angrycoder and the grumpycoder bashing up the servers at the data center for all you know :-) . However, that is where you implement leanancy that if your control has not contacted the web service for two weeks (if we bash up the data center pretty bad) then licensing exceptions will occur.

Obviously, before the exceptions begin to be thrown, what is required is that the developer of that site is warned that the license is not being confirmed by the web service because it could be contacted.

---

On another note, for domain based licensing, you should have the unlimited localhost access. It should not be based whether the "server name" is localhost -- it should be based on IP where the IP address is 127.0.0.1. Why? Because you have situations like this happening:

http://blogs.aspadvice.com/jlovell/archive/2004/01/22/373.aspx

BTW -- we still have to tackle "watermarking" (I believe the term was) your assemblies for the just-in-case a stupid developer copies the code that he from reverse engineering. .NET (and Java) have this "problem" that makes you feel that sex without a condom is safer.

---

-- Justin Lovell

Open License looks like it has a great potential for filling a real void. problem is they have zippo in the way of documentation.

A catalog of classes is *not* documentation!

I would agree. However right now Open License is being developed by one person with very limited time. I have been focusing on a major issue that was found and haven't had much time to do documentation and examples. The problem has to do with the encrypted file not being decrypted by the Open License Provider. Once this is solved I hope to include more examples and I'll try for better documentation. Thank you for the feedback.

Also what kind of documentation are you looking for? The .NET framework is documented using the catalog of class you are referring to. So can you clarify so I can try to develop something you and other may find useful. Thanks.

Also if anyone would like to help please let me know. There are many areas that I could use assistance in.

Steve Paulin
SP extreme
[email protected]

---

SP extreme

http://www.spextreme.com/

Hi Steve,

I saw the other thread that you had regarding that problem. I have flagged it and what did not motivate me was that you did not post some source code and details on how you went about encrypting (and decrypting) your license file.

It is not that you "do not have an interesting topic", I am very interested in these things, but it lacks content on which I can answer your post. Sure, I could have just downloaded the source but it will take time to dig in where everything is.

Like what has already been said -- a list of classes does not constitute as good documentation. What is good is to follow the .NET SDK's example. Why? Because it lists what it members do. It is no good saying "the name says it all" -- you also got to list the exceptions that you throw if something goes on... also things like "this method uses the data in this and that property"

My time is also somewhat restricted -- I only come to these forums in my spare time (programming is not even my main profession). I do spend a lot of time here (30 minutes to one hour a day). When I get the spare time, I will try to get into OpenLicense and sort things out. One thing that I have to raise with you is: which source repositry is the main one? I see that you have four! If I can remember correctly, Tigris runs on SVN... and the rest in CVS. I prefer SVN myself -- I have it running over here.

---

-- Justin Lovell

Thanks for the feedback. The tigris is the main repository and i've been using CVS with it. Haven't been successful with the SVN.

I'll take a look at my other post and see what I can add. It may have changed too.

Like I said I try and improve the documentation as time goes on, but for now basic functionality is still needed.

Steve
http://www.spextreme.com/

---

SP extreme

http://www.spextreme.com/

Sorry for deviating from the main topic but source control calls. Ok, one question for the CVS: do you use the shell add-in (which I had success with that) or do you use the VS.NET add-in (some funny name: Ijuba or something like that)? It is just that I have not had success with the later.

---

-- Justin Lovell

I don't use VS at all. Don't own it. I've been using #Develop(SharpDevelop).

I've been using Torteise(sp) CVS which is integreated into the menu system of Windows XP. Really nice and easy to use.

Steve

---

SP extreme

http://www.spextreme.com/

I had built my own licensing scheme for my controls and was even considering making it into a product. Xheo Licensing came out and looked so feature rich that I decided to avoid that market and stick with what I do best. I still use my licensing scheme but wouldn't encourage you to try to reproduce something like it. For example, my web site has been coded to email unique, serialized and encrypted license files to customers. Do you want a system that involves your web site like this? I suggest working with a system that is proven and has expertise behind it.

---

--- Peter Blum
Creator of Professional Validation And More Suite, Peter's Date Package, and Peter's Polling Package
www.PeterBlum.com

The concept of Open License is to provide an alternative to XHEO license. The benefit to this is by making it open source, a group of individuals can help to advance it. Personally I have a vision of where it should go. Maybe other see it going another direction.

XHEO is very expensive. Especially if you want the code so you don't have to deliever a second DLL with your product.

Open License's goal is to provide an alternative. If it gets support and takes off great. If not, then oh well I learned a lot about .NET License Manager and have starting point for my on scheme.

Personally though I'm hoping that .NET users begin to show an intrest in advancing this. There have been a lot of downloads of it but it still lacks a lot of features. I'm hoping to change that.

steve

---

SP extreme

http://www.spextreme.com/

I was thinking about domain based licensing. How would you handle situations where users don't own an actual domain name, but use a host such as Brinkster or WebHost4Life?

How would you prevent someone from registerering a domain such as www.brinkster.com and then sharing the license with multiple people using the same host?

---

Brian Price
Co-Author of UCanUse Products
UCanUse.com
Wittysoft, LLC

Thats would be a tough one. You would probably have to use a combination of constraints. What the combination would be I'd hae to look into and think about. The design of OpenLicense though would allow building almost any type of constraint fairly quickly. So once the constraint types were figured out it probably would be easy to build.

Some ideas on the top of my head. You would have to use domain licensing. Then added may a machine(this would prevent multiple machines from running it but if they had all domains on a single machine then it wouldn't stop that). Then add in a instance. This would be harder since you would somehow have to identify the instances running within the different web applications space on the single machine. Not sure how that could be done.

Like I said this is just a quick guess off the top of my head. I'm not sure if XHEO would be able to support this with their current limits. They support Domain/IP limits and Session but I believe that is only in the current web space.

I'd love to hear other ideas. Maybe this is something to look at adding to Open License in the near term.

Steve

---

SP extreme

http://www.spextreme.com/

This extends my idea of using web services to check up the license. The web service can revoke licenses as well...

But when you get a license for a domain, you can have a log system running in the background to see which domains are being registered. And obviously, when you catch a oddity like "brinkster.com", you can then take action. But there is one problem -- some sites are divided by sub-domains... one example is Microsoft. They have support.microsoft.com and msdn.microsoft.com, ect., ect.

:: Then added may a machine(this would prevent multiple machines from running it but if they had all domains on a single machine then it wouldn't stop that).

You are forgetting the fact that there are web farms. One web site can reside over two or three servers. An example www.aspalliance.com.

But I think it will come down to trust as well. No licensing technique will be able to conquer all types of piracy but you can help deter them with the licensing. You might spend a lot of time on your licensing schema but there is one consideration that you have to take: the ability to accomodate all types of enviroments (online and offline)... and that always creates a hole for the quick cracks/patches to your application.

---

-- Justin Lovell

One solution would be to check the domain during product activation. The concept of a verified domain could be introduced as follows:

1. The user goes to the licensing website and enters the domain name they want licensed.
2. They are given a verification key in the form of a file.
3. They put this file at the root level of their domain.
4. They go back to the licensing website and re-enter the domain they want licensed.
5. The licensing server checks their domain for the verification file and issues the domain-based license.
6. The user can then remove the verification file from their website.

This method could be used to guarantee that the user has access to the root level of their domain name. In my opinion, this proves ownership of the domain.

I realize that this solution places a burden on the person registering for a domain-based license.

Here is an alternative solution, which is easier for the user, but more complex to implement, (I hate complexity in licensing solutions because it's nearly impossible to test for all client-install situations)

The user could register a url rather than domain-name. At runtime the license could verify that the licensed url maps to the root of the web application. I believe that most hosts isolate the web applications of their clients for obvious reasons. This would prevent sharing a single license between multiple accounts.

---

Brian Price
Co-Author of UCanUse Products
UCanUse.com
Wittysoft, LLC

I think that sub-domains are more of a problem when defining the license agreement than when enforcing it. Sub-domains fall into a gray area because they can be used to either organize the content of a single site or to divide a site into multiple sites on a single server.

It's up to the issuer of the license agreement how to handle sub-domains When defining a contract the licensee has to choose one of the following:
1. Sub-domains could not be allowed.
2. Sub-domains could be allowed without restriction.
3. Sub-domains could be allowed but the licensing agreement could state that sub-domains must all refer to the same site.

As for enforcement:

1. Regular domain-based enforcement could be used. each sub-domain could require a separate license (this could be implemented in a single license file).

2. Domain-based enforcement could be used in combination with pattern-matching. For example, *.microsoft.com

I agree that it comes down to trust. Regardless of how it's implemented domain-based licensing will be a burden on the users. If you decide to offer a licensing model for developers and allow them to redistribute your control, domain-based licensing is no longer applicable. In this scenario you could use a licensing policy that checks the public key of the calling assembly. However, I think that for most situations this would be too much. Besides if you offer the source for your control you ultimately trusting your customer completely.

It's definitely a balance between trust and effort. The most you can achieve with licensing is to make it more difficult to pirate your control than develop an equivalent one, or in the case of .NET pull the source from the assembly itself

---

Brian Price
Co-Author of UCanUse Products
UCanUse.com
Wittysoft, LLC

Just to expand the idea of "domain based license". Have two levels:

* www.foo.com and foo.com are allowed.
* Special requests for the *.foo.com are allowed (maybe with a small fee attached) that would have some sort of follow up.

---

-- Justin Lovell