Re: [platform-update-dev] Role Based Updates

[Christophe Elek <celek@xxxxxxxxxx>]

a) authenticate user when user selects a role
        1) how do we get
the list of available roles ?
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/disable and
uninstall uneeded plugins
 
JAAS, JCE and JSSE are part of JDK 1.4,
if we run on JDK 1.4 we have it for free

So we can start in 2 separate areas
1) authentication/authorization which will
return a 'set of features/plugins to enable'
2) once we have the set, download/enable/disable/remove
features

Should we use the 'configuration.xml' as
the file that will be 'transmitted' ?
Should the 'download' of plugins also be
'authenticated' ? (using user's credential) ?

Maybe the best is to start designing it
and see what the community has to say ?

---

  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: platform-update-dev-admin@xxxxxxxxxxx

02/20/2005 01:09 PM

Please respond to
platform-update-dev@xxxxxxxxxxx

To	platform-update-dev@xxxxxxxxxxx
cc
Subject	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


_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev