[dev] gollem authentification via Horde

Brent J. Nordquist bjn@horde.org
Wed, 4 Jul 2001 16:09:49 -0500 (CDT)


On Wed, 4 Jul 2001, Jon Parise <jon@csh.rit.edu> wrote:

> Alright, I'm going to go ahead and clear all of this up.

Excellent summary and refocusing, Jon; thanks.  My questions:

> The problem is holding onto the login credentials once the user
> has been successfully authenticated
> [...]
> The problem arises when we look at applications like IMP or
> Gollem.  Those applications require the web user to authenticate
> themselves to a particular service (IMAP, FTP)

Sure.  But don't we already do that today (store the IMAP user and
password for later use)?  (Because each page refresh potentially may need
to reopen a new IMAP connection... a persistent IMAP connection isn't kept
open?)

> The other end of this solution involves storing the pass phrase
> somewhere else, keeping the two keys separate, less they combine to
> summon Gozar the Gozarian.

<grin> "The next time someone from another dimension asks you if you're a
god, you say:  YES!"

Well, if (for some Horde apps) we already have to persist login+password
pairs (or more generally, "credentials") somehow,

(a) couldn't this be done at the Horde level (centrally), and

(b) couldn't each application, when it needs to connect to an external
service (IMAP, FTP), try all the existing stored credentials first (thus
only requiring a login prompt if none of them work, and then storing that
one too)?

That would allow sites that have a unified back-end authentication system
to achieve single-sign-on with all the Horde apps.  There are security
concerns here, certainly.  But we're going to get a lot of pressure, I
think, to provide a single-sign-on feature... I know here, having to log
into the different Horde apps separately will not fly.

The details of how to do the persisting in the most secure way obviously
needs discussion too.  But IIRC Chuck recently implemented a way to
encrypt the data such that neither the cookie nor the server have a
plaintext password?  (I'm fuzzy on the details now.)

-- 
Brent J. Nordquist <bjn@horde.org> N0BJN
Yahoo!: Brent_Nordquist / AIM: BrentJNordquist / ICQ: 76158942



>From chuck@horde.org Date: Wed,  4 Jul 2001 17:49:13 -0400
Return-Path: <chuck@horde.org>
Mailing-List: contact dev-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list dev@lists.horde.org
Received: (qmail 92794 invoked from network); 4 Jul 2001 21:50:56 -0000
Received: from 208-59-250-206.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO marina.horde.org) (208.59.250.206)
  by horde.org with SMTP; 4 Jul 2001 21:50:56 -0000
Received: by marina.horde.org (Postfix, from userid 33)
	id C364939F3; Wed,  4 Jul 2001 17:49:13 -0400 (EDT)
Received: from 192.168.0.103 ( [192.168.0.103])
	as user chuck@localhost by marina.horde.org with HTTP;
	Wed,  4 Jul 2001 17:49:13 -0400
Message-ID: <994283353.3b438f59a3ec2@marina.horde.org>
Date: Wed,  4 Jul 2001 17:49:13 -0400
From: Chuck Hagenbuch <chuck@horde.org>
To: dev@lists.horde.org
References: <3B410B49.3E92756C@developer.ch> <994132061.3b41405d7904f@marina.horde.org> <3B41D564.55898F1F@developer.ch> <994170581.3b41d6d5d8458@jan.dip.ammma.net> <3B4204BD.CD56BD74@developer.ch> <994200632.3b424c384f69a@linux.wg.de> <003601c1049d$db0f63c0$01000001@lundeman> <994273151.3b43677f0529d@Mail.SavvyWorld.Net> <20010704151920.A28459@csh.rit.edu>
In-Reply-To: <20010704151920.A28459@csh.rit.edu>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Subject: Re: [dev] gollem authentification via Horde

Quoting Jon Parise <jon@csh.rit.edu>:

> Alright, I'm going to go ahead and clear all of this up.  I think
> most of you guys have sort of run astray of the real issues here.

For the record, Jon's summary of the issue is accurate and I agree with it, and 
all discussion should follow from that.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
Some fallen angels have their good reasons.


>From chuck@horde.org Date: Wed,  4 Jul 2001 17:51:48 -0400
Return-Path: <chuck@horde.org>
Mailing-List: contact dev-help@lists.horde.org; run by ezmlm
Delivered-To: mailing list dev@lists.horde.org
Received: (qmail 93129 invoked from network); 4 Jul 2001 21:53:32 -0000
Received: from 208-59-250-206.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO marina.horde.org) (208.59.250.206)
  by horde.org with SMTP; 4 Jul 2001 21:53:32 -0000
Received: by marina.horde.org (Postfix, from userid 33)
	id 17B7E39F3; Wed,  4 Jul 2001 17:51:49 -0400 (EDT)
Received: from 192.168.0.103 ( [192.168.0.103])
	as user chuck@localhost by marina.horde.org with HTTP;
	Wed,  4 Jul 2001 17:51:48 -0400
Message-ID: <994283508.3b438ff49e45d@marina.horde.org>
Date: Wed,  4 Jul 2001 17:51:48 -0400
From: Chuck Hagenbuch <chuck@horde.org>
To: dev@lists.horde.org
References: <Pine.LNX.4.33.0107041547570.5491-100000@kepler.acns.bethel.edu>
In-Reply-To: <Pine.LNX.4.33.0107041547570.5491-100000@kepler.acns.bethel.edu>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Subject: Re: [dev] gollem authentification via Horde

Quoting "Brent J. Nordquist" <bjn@horde.org>:

> Well, if (for some Horde apps) we already have to persist login+password
> pairs (or more generally, "credentials") somehow,
> 
> (a) couldn't this be done at the Horde level (centrally), and

Yes. I've been meaning to write a Credential system for a while.

> (b) couldn't each application, when it needs to connect to an external
> service (IMAP, FTP), try all the existing stored credentials first (thus
> only requiring a login prompt if none of them work, and then storing that
> one too)?

No; that'd send username/password combos to services that didn't necessarily 
deserve them. But I'm nitpicking with that specific, really. If we had a 
reasonable way of determining which credential went with what, it should be 
fine.

> The details of how to do the persisting in the most secure way obviously
> needs discussion too.  But IIRC Chuck recently implemented a way to
> encrypt the data such that neither the cookie nor the server have a
> plaintext password?  (I'm fuzzy on the details now.)

The Secret class does a pretty good job, IMHO, of taking care of sensitive data 
in a session.

-chuck

--
Charles Hagenbuch, <chuck@horde.org>
Some fallen angels have their good reasons.