[news.eclipse.technology.etf] Re: Licensing framework with ETF?

[Christophe Avare <christophe.avare@xxxxxxx>]

Paul,

This is good news.

The kind of use case i envision is an RCP based application whose features are 
downloaded via the update manager, or through the standard zip install.

Each feature contains a first level of go / nogo, ie a mechanism stating that 
this feature set is allowed to run or not.
This requirement must be based on some credentials previously granted to the 
platform as a whole (kind of policy file).
I have no precise idea by which means those credentials are installed, but some 
kind of request to a remote "license server" that generates the license based on 
some identification information (password, payement checking, ...) and install 
it on behalf of the user is the mainstream process i guess.

I also think that no permanent access to a license server should be required 
thus a local key store is necessary.

I think that two classes of permissions are required:
- One based on can / cannot do something
- another based on a timestamp: this is useful when a "demonstration" version is 
deployed, but whose functionnalities are available only for a limited period of 
time. Installing a real license is then the only way to reactivate the functions 
(well, maybe it means the license itself has expired...).

Considering the Eclipse platform itself, as a developer i expect to have some 
secured extensions, which means that the extension (maybe knowing its id) is 
deactivated / activated at load time by the framework based on the license 
information.
But this will surely have a huge impact on the low level (OSGI?) runtime of Eclipse.

Maybe, a more manageable situation is to have two plugin.xml: the standard one, 
and another one encrypted with the platform wide key: extensions that are 
sensitive to the security issues are put in this file and merged only if the 
plugin descriptor can be decyphered.

I will actively monitor the progress of the your project because we have a 
strong interest in the field.

Regards.
--
Christophe

Paul Trevithick a écrit :
> Hi Christophe,
>
> The short answer is yes, this is within scope.
>
> I see three fairly distinct sets of concerns here. The first set is related 
> to the licensing tool user experience. Another is the "secured vault" API 
> supported by authentication plug-ins. The last set is the authorization 
> issues--allowing/disallowing features and/or installation itself.
>
> I think of ETF as mostly concerned with the second set of issues while 
> trying to create an extensible framework to support the other two. I'm 
> fairly certain that we will have to work with other Eclipse groups on the 
> third set of concerns. Low level plug-in security models and implementation 
> are not presently considered within the scope of ETF.
>
> Can you tell me what kinds of authentication you're thinking about? Do you 
> envision an online registration mechanism? Do you have some ideas about how 
> fine-grained you like to control feature authorization?
>
> Paul
>
> "Christophe Avare" <christophe.avare@xxxxxxx> wrote in message 
> news:crp84o$uk6$1@xxxxxxxxxxxxxxxxxx
>
> > Hello,
> >
> > some time ago, i (unsuccessfully) tried to find a licensing tool that can 
> > work closely with the Eclipse framework.
> >
> > The basic need is to have a plugin / fragment contributions conditioned by 
> > the presence in a secured vault of some credentials.
> >
> > This way, one can deliver a complete application and distribute license 
> > with grants that activate or not some features (some of them may be 
> > temporarily granted for an evaluation period): this is a complementary 
> > view of the feature sets.
> >
> > It this kind of support is in the scope of ETF itself, or a technical base 
> > on which some licensing tools can rely ?
> > --
> > Christophe A.