Re: [equinox-dev] authentication vs authorization

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

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).

Jeff

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

02/24/2006 03: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