Re: [Evolution-hackers] Authentication/Password Issue in Evolution Data Server .....

[Chris Toshok <toshok ximian com>]

The authentication support in the addressbook is kind of sticky, yes.

The main issue that brought about the current architecture is that the
user might configure evolution to authenticate to an ldap server that
might otherwise not require it.  LDAP servers exist (in fact I
administer one) that work for both anonymous and authenticated access. 
They typically just prune the set of attributes/entries they show to
unauthenticated clients.

Given that we didn't want to be adding username/password to the uris we
were sending the wombat back in the 1.x days, this meant the UI had to
be the one that authenticated.  Also, it lead to some icky interactions
when the UI calls a corba method in the wombat, then the wombat calls a
corba method on the UI to pop up the password dialog... this was a
recipe for blocking in the old architecture, and both UI and wombat
would deadlock.  Making it async made things even more complicated. 
This should be much more easily solved with the new e-d-s code.

The thing about requiring authentication once-per-uri as opposed to once
per client already holds, since e-d-s hashes backends by their uri, and
all clients that load the same uri share the same backend.  That is,
once one client authenticates, they are all authenticated.

I agree that e-d-s should be the place where passwords are managed, but
that requires idl changes, libebook api changes and some rearchitecting.

Chris

On Wed, 2004-03-10 at 04:49, Amit Shrivastava wrote:
> Hi,
> 
> I am using evolution-data-server API to get addressbooks data for OO.o,
> so at the backend it uses ldap server, groupwise servr etc based on the
> URI. 
> 
> For authenticating to the backend server like ( ldap server, groupwise
> server etc ), it is required to provide password for each of the server
> and manage these passwords in the client, "evolution" also
> caches/manages these passwords , similarly each of the client have to do
> password some management. Which is not a good thing. 
> 
> It should be such that once a client ( either evolution ) provides the
> password it should be cached by the eds server and managed subsequently
> and the client should'nt care about the backend authentication. I hope
> we can avoid even first time password something like iLogin, once I
> login in my desktop i dont need to provide password for any applications
> :-).
> 
> It will be good option that the passwords for the backends are managed
> by evolution-data-server, and client just need to tell other
> configuration parameters, and never meddle with the passwords.
> 
> 
> regards,
> Amit 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers