Re: [equinox-dev] authentication vs authorization

["Neil Bartlett" <neil@xxxxxxxxxxxxxx>]

Scott,

You're right that this is a requirement for a lot of RCP developers,
especially those of us developing in-house corporate applications.

The problem is that there is a wide and multifarious range of
scenarios that need to be supported. For example:

1) Some people want an application that still runs in a limited mode
if users fail to authenticate.
2) Some people want to allow users to log in and out without
restarting the workbench - in particular the Open Healthcare Framework
guys need this.
3) Some people want to have a server dynamically supply the whole
application depending on the user's role...that is, they want IBM
Workspace Client without paying for it :-)
4) Some people want the authorization of plugins controlled according
to the user's role, but also need their application to run offline.
5) Any authorization framework that works by controlling access to
plugins has to interoperate with Eclipse Update.
6) Some people need to authorize access to functionality on a sub-plugin level.

My own project Eclipse-JAAS can support only some of those needs. To
do more requires (I believe) some modifications to Equinox. For
example it would be great to be able to hook into the extension
discovery mechanism so we can filter out extensions the user shouldn't
see.

I think there needs to be a dialog between the Equinox security group
and those of us who are trying to write secure RCP apps. For my needs
in particular, bundle signing and Java permissions are irrelevant
(although Sword4J is very cool). It's not the code I don't trust, it's
the users!

- Neil




On 2/24/06, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
> 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
>