Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-update-dev] Role Based Updates 
Christophe Elek wrote:

Bob, yes, I would add the 'authentication' part too


Ok.


a) authenticate user
      either client or server authentication
b) associate user with policies (roles or whatever we want to call it)
      install policy or acl server (like IBM policy director)
c) associate plugins with role
      credentials for authentication from policy server
d) download/install/update
e) enable plugins


And disable.


So it seems possible, now what would the use case be ?

a) user 'logs in the workbench' which shows roles that are enable ?
or
b) user attempts to enable role and we authenticate ?
I would think it possible that some roles might not require authentication. This would argue for b. 


I agree the 'log-in' is probably the best , so we need a client
authentication, like JAAS that would then connect to server ?
If you're going to do authentication, you'll need encryption, but I'd like to know what kind of bloat JAAS, JSSE and JCE would add to RCP? RSA public key encryption is dead simple for encoding small text like user names and passwords and can be processed by any standard http server. (I've done it in PHP and Java.) 


This should
be done at startup right ?
I'd think so. Inevitably, someone will ask for the ability to change roles while Eclipse is running, but that is a usability not a functional need. 

Bob
PS Is there a reason your reply was cross-posted?
(Embedded image moved to file: pic10360.gif) Christophe Elek IBM Software Group - Toronto Lab Technical Team Lead - Cross product Tech Support Cross components problem resolution specialist Eclipse.org - Platform Core development Phone: 905-413-3467 T/L: 969-3467 Toll Free: 1-800-IBM-SERV Email: celek@xxxxxxxxxx
Bob Foster <bob@xxxxxxxxxx> Sent by: To platform-update-d platform-update-dev@xxxxxxxxxxx ev-admin@eclipse. cc org Subject Re: [platform-update-dev] Role 02/19/2005 04:11 Based Updates PM Please respond to platform-update-d ev@xxxxxxxxxxx 



There are four parts to this, right?

a) Associating a list of allowed plugins with a role.
b) Associating a role with a user.
c) Downloading/installing missing/updated plugins for role.
d) Enabling role plugins and disabling all others.

Steps a and b can be done on the server. Steps c and d UM needs to do.

In other words, solution #2.

Bob Foster

Christophe Elek wrote:


Ok so do we work on 'dynamically installing plugins based on policy for a
specific user' or' allow runtime use of plugins based on role' ?
If this is install, I can see the following

1) Hook the start-up as Jeff mentioned to get User authentication
2) get user authorization/policy/ACL -> From a server ?
3) retrieve list of plugins and location
4) call UM to install plugins and enable them

or

1) Hook up startup to call UM server
2) server does authentication and authorization
3) UM installs list of feature that the server passes back

Any other solution ?
I like #2 as we leave the implementation to the User.





(Embedded image moved to file: pic17763.gif)  Christophe Elek




IBM Software Group - Toronto Lab




Technical Team Lead - Cross product Tech Support




Cross components problem resolution specialist




Eclipse.org - Platform Core development




Phone: 905-413-3467 T/L: 969-3467 Toll Free: 1-800-IBM-SERV




Email: celek@xxxxxxxxxx













            "James D Carroll"




            <jamesdcarroll@ho




            tmail.com>


To


            Sent by:                  "Eclipse Update"




            platform-update-d         <platform-update-dev@xxxxxxxxxxx>




            ev-admin@eclipse.


cc


            org



Subject


                                      [platform-update-dev] Role Based




            02/19/2005 12:36          Updates




            AM






            Please respond to




            platform-update-d




             ev@xxxxxxxxxxx









Hey guys,
Sorry its been a while. Work's been a bear lately.  Anyways....

In case you had forgotten the basic idea was that I wanted to see if


there


is a way (and if not what can I do to make real) the following basic Use
Case:

1. User starts Eclipse
2. Eclipse presents user with login/password screen
3. Eclipse presents with user with only plugins that they need

I've done some more reading (what a concept, huh?) and I am almost
convinced
that it could be accomplished using the existing platform. Alot of the
pieces seem to be in place, especially after reading the parts in Help
called "Enable, disable, uninstall a feature", "Update policy", and
"Automatic update scheduler".

There were also lots of great questions that I'll summarize here so that


we


can hopefully make this a reality.

1. What about the initial install?
Yes, there would have to be some kind of initial installation that takes
place, beyond the scope of this request. The absolute Eclipse core and
maybe
a config file of some kind that tells the Platform on startup that its in


a


Role based installation/management environment and where to go to learn
more.

2. Do you cache plugins or download everytime?
I can't see a problem if there are plugins resident on a computer, as


long


as the person who is currently logged in, can only access those features
that they are allowed. This is where the existing ability to disable
features can come in handy. The key would be to not allow someone to
activate a plug-in that they shouldn't.

3. Not all plugins can be dynamically loaded
Not my problem. As an optional feature targeted to business users it


would


be their job to make sure that what's downloaded to their machines works.
Our job is only to enable automatic Role specific requests.  The site
queried would be responsible for returning correctly.

4. What this about licensing?
License management is a side benefit of this request.  By providing a
framework, others can create centralized management tools (or maybe we
could
create a reference implementation). For instance, a company might buy a
"global" license,  a "site" license, or a set number of licenses. The
providing company could give the purchasing company a key that they enter
into the central server. How the server responds the request is up to


them.


The key is to increase the granularity of the request from "anyone who
stops
by" to "who are you".

5. Does anyone really want this?
I think this hinges on two key factors: what is the current situation?


and


what is the future of Eclipse?

The current situation is that there are companies out there who sell


vastly


overpriced pieces of software whose sole purpose is to distribute


software.


Think MS's SMS, Novell's Zenworks, or IBM's Workplace technologies. So
what's the difference between them and Eclipse?  The ability to
differentiate between one user and another.

As for the future of Eclipse I see this as the only alternative.  Its


hard


to see now with so much work to be done, but eventually Eclipse will have
to
move from the Java hobbyist to the Java shop. And when that happens there
will be Managers. And they'll want to know this and control that and
because
they hold the purse strings nothing will enter their world unless they


can


know this and control that.  And when Eclipse becomes the de facto


standard


for desktop integration (because somewhere somehow someone will say to
themselves "I'd like to create an Eclipse plugin, but does the world


really


need another ANT plugin? How about an SMTP mail client?)  it will only


get


worse.

And at the bottom of the whole mess will be (should be) the most basic
question that only the Update component can answer:

Where do you want to go today?


James

Back to the top