Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] authentication vs authorization


Okay, this clarifies a lot. So, you want a user preference type service to store the authentication information for remote machines, and you want to be able to authenticate users locally. UserManager should be able to provide the backend for the latter. Some of the features of JAAS purport to supply the front end for the latter. I would also like to see a nice user facing security model for Eclipse that would make sense for users. The simplest version would be that a user simply logs in and there is a property or service or extension that tells who the current user is. I am particularly interested in such a user facing model so that it could be tied into ConditionalPermissionAdmin using a new Condition implementation.

There is a nice description of ConditionalPermissionAdmin in the OSGI R4 specification, which can be downloaded from the www.osgi.org site. (Follow the OSGi Technology link.)

ben



Scott Lewis <slewis@xxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

02/24/2006 12:02 PM
Please respond to Equinox development mailing list

       
        To:        Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
        cc:        
        Subject:        Re: [equinox-dev] authentication vs authorization



Hi Ben,

Well, one simple use case of immediate interest to ECF users

1) user starts Eclipse
2) they want (via ECF) to be automatically connected to their 3 (n)
IM/other remote accounts upon startup
3) Each of these accounts has a) service type/protocol (URI) b)
username; c) password and/or other credentials

Think GAIM.

And each of the n accounts that are connected really *should*, it seems,
be determined by some notion of an authenticated platform user...with an
associated user-specific secure datastore rather than have it be shared
for every person that starts Eclipse and runs ECF plugins (i.e. which
would be the case if ECF just stores all of this info in the preference
store).  Of course it's not limited to ECF plugins...team plugins/CVS,
soap services plugins, etc., etc.

If there are docs on the ConditionalPermissionAdmin I can/will take a
look at them...I was unaware of it...but does it deal with the (pretty
mundane I know) use case above or is it intended for something else?

Thanks,

Scott


Benjamin Reed wrote:

>
> Scott,
>
> Could you provide an example of what you are talking about? The
> ConditionalPermissionAdmin was designed with the flexibility to
> address some of the things you are talking about in the mobile phone
> space, so it would be good to get a feel for the aspects that you see
> that are lacking. An example would help understand what is missing to
> accomplish what you need.
>
> thanx
> ben
>
>
>
>
>                  *Scott Lewis <slewis@xxxxxxxxxxxxx>*
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>
> 02/23/2006 07:28 PM
> Please respond to Equinox development mailing list
>
>                        
>         To:        Equinox development mailing list
> <equinox-dev@xxxxxxxxxxx>
>         cc:        
>         Subject:        [equinox-dev] authentication vs authorization
>
>
>
>
> I think I speak for a number of folks when I make the assertion that we
> would like to see both authentication and authorization added to the 3.2
> release of the platform.  This is particularly true for projects like
> ECF, where having some way to authenticate the local user and get access
> to secure credentials for accessing remote accounts is very important.  
> Of course, in the long term it's also important that there be some way
> to secure access to runtime bundles...and run potentially untrusted code
> (at least not completely trusted code).
>
> There is, I think, a real need for the emerging RCP app development
> community to have at least a first cut authentication/login security in
> Eclipse 3.2.  Although I think it would be terrirfic to have a general
> solution for authorization as well in that timeframe, I think
> authorization is more clearly more important for most app
> developers...as I think it would be a serious problem for app developers
> using RCP to have to wait beyond 3.2 for *both* authentication and
> authorization.
>
> Why?  Well, I suspect that many app developers will need to either a)
> begin implementing their own authentication approaches in order to
> create/build their apps; or b) not use RCP at all as the basis of their
> applications.  Obviously, neither a nor b are desireable from the point
> of view of broadening equinox's usage in the app developer community.
>
> So, enough speech making...I just wanted to convey to people what I
> perceive as at least one serious need for equinox in the 3.2 timeframe.  

> I know all of you are aware of that need, so I suppose I just wanted to
> make it clearer from the point of view of app developers that would like
> to use equinox as the basis of new, secure, non-IDE applications.
>
> Thanks for listening,
>
> Scott
>
>
>
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>equinox-dev mailing list
>equinox-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/equinox-dev
>  
>


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



Back to the top