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

My naive view of this tells me that three gross-level things are needed.
- authenication (figure out who the user is)
- credential store (keep information according to the various users)
- authorization (control what various users can do)

The most likely scenarios for the 3.2 time frame is that we get authorization based on an extensible JAAS mechanism.  Neil has something along these lines and Jay/Matt are in the final throws of getting permission from their managment to contribute their infrastructure.  Between the two of these we should end up with a story.

A credential store would be great to have but it is unclear where to get/how to create one that solves the case that Scott outlines.  Effectively you want some some secure store that can be used to manage users names/password for various servers (amongst other things).  Seems that the mechanism might not be so hard as figuring out the right organizations/API/structure.

Authorization is cool but I believe that it basically relies on having secure code wrt Java 2 permissions.  The Security workarea team in the incubator has made good progress on proving that this is possible and does not have a signficant impact on performance (with security manager turned off).  The challenge going forward is to figure out how to integrate this effort with the mainstream development and keep the code secure over time.  This is more of a people issue (education/organisation/commitment) than a technical one.  Of course there is also the permissions design issue as you may need a different permission vocabulary in the context of different bundle domains (e.g., permissions for drawing on the screen).  Someone has to design those.

Summary:  The news is good in that we should have some reasonable authentication story in the 3.2 timeframe.  That should address several usecases that are hitting people right now.  The other news is not so bad in that we can add/build the credential store whenever it is available (i.e., we don't have to wait until 3.3).


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

02/24/2006 03:02 PM

Please respond to
Equinox development mailing list

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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?



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 mailing list