RE: [SM-USERS] Authorisation split up SM-app / SM imap-service )

[Erin S. <si...@ha...>]

Maybe I'm missing the point, but isn't this what phpGroupWare
already does?  Seems to me that SM should stick to it's forte -
being an excellent WebMail client, and trust to other applications
(like phpGroupWare, or whatever else is in store from this ZooKeeper
stuff) to manage upper-level integration.

It's been mentioned before that SquirrelMail is offered as a plugin
to phpGroupWare, and that application is designed around allowing a
single point of access to many applications.. SO.. maybe more of a
happy marriage between SquirrelMail and higher-level "Container"
applications would be more appropriate than trying to have
SquirrelMail do it all...

Just my .02 =)
Erin
(sizzle)

-- 
'Waste of a good apple.' ~Samwise Gamgee
(ICQ: 36870353)


> In my opinion you can split the whole security thing into 2
things:
>
> 1] access to the webapplications (SquirrelMail)
> 2] access to the service (IMAP)
>
> In Squirrelmail we make use of authorisation by the imap-service
to have
> access to the web application Squirrelmail.
>
> What I want is to split those things so it can be possible to make
use of
> Squirrelmail for other services then imap. Imagine a webmail
application with
> access to multiple IMAP-servers, NEWS, POP3 etc etc.
> If we achieve such a application we no longer can make use of the
primary
> authentication alone. In most cases usernames password paires
differs for each
> service. (It should be configurable that a service can fallback to
the primary
> authentication so there is no need to enter usernames / passwords
twice or
> there is no need to store usernames / password(encrypted!) pairs
in the
> user.pref file).
>
> The only thing what currently is missing is a way to savely store
the
> usernames / password pares in the userpref file in case we realy
split the
> authorisation to the webapplication and the installed services.
>
> If somebody has a realy nice, very secure sollution for this then
mention it
> so we can have discussion about security.
>
> Regards,
>
> Marc groot Koerkamp
>