Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 209.85.210.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FC0CB01.6060402@die-schneider.net>
References: 
 <CAEQV+EEguaRY9dvaFS7WcSDmTeP=y_WZHvkyDdB2AjcrPf_+1A@mail.gmail.com>
	<CAEQV+EFyv54tE4zsrXw-rCRrmDna5apcF=f=0HNQSUyQKi4s7A@mail.gmail.com>
	<CADHGh9WrVoPdnae4QgbTw-HeCVJ0SvXObJt++3JaK483THdChA@mail.gmail.com>
	<CAEQV+EGmuw4rVpr1cTJH+w_rhcgxg=_pBfCtpgJnPiZgBu_2Lw@mail.gmail.com>
	<4FC0CB01.6060402@die-schneider.net>
Date: Sat, 26 May 2012 15:32:19 +0200
Message-ID: 
 <CAEQV+EEXYpx60MPV+k2Ar50cHcpLD6NDL8jWnNKdFB45OKm8sw@mail.gmail.com>
Subject: Re: [HEADS UP] Ssh agent and key authentication support
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@karaf.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Karaf can only generate a private key for the user which is actually
running karaf, not for others.  The reason is that private keys need
to be only readable by the user, and only the user (or an admin) could
do that.  Also, I really don't think Karaf should mess with the ssh
setting of the OS at all.

If we want to integrate with the OS, that is doable (but that's a
different problem) using PAM.  SSHD has a sshd-pam module which I
started a while ago, but didn't really finished for lack of a good
java pam library with java.  And also because I doubt people would
really want to use that in production (I have never seen such a
requirement yet).  It could also be done using Kerberos, but that's
not something which should be enabled by default.

I don't think we should make things more complicated than they are.
The security mechanism of Karaf rely on JAAS, so it's really
pluggable.  The default implementation provided by Karaf should be
simple enough that it can support being secured and easily manageable.
 I don't think it should be tied to the OS or even try to be the best
security system.  There are very good products that already do that
and that's not really Karaf goal, it should just be able to integrate
with those using LDAP for example (so I guess at some point, we need
an LDAP login module for key based authentication).

One thing I really focus on is ease of use.  At dev time, we want
Karaf to be the easiest to use as possible. So that people can
actually download karaf, try and experiment without being bugged by
too many things to do and understand to be able to try things. Having
a secured security system by default would also be a problem when
writing system tests that use multiple instances too.
At prod time, we want Karaf to be easily secured.  Changing the
etc/users.properties and etc/keys.properties to secure Karaf really
seem a good compromise to me, in conjunction with a big red warning
when Karaf is started in dev mode.

Christian, even if Tomcat changed its default security to be more
secured, I don't think we should do the same.  Karaf is (by far) not
as popular as Tomcat, and Tomcat does not have the same need as Karaf,
i.e. be able to propagate security tokens from an instance to another.
 And if we want Karaf to become popular, once again, we need to be the
easiest to use, which means, you should start it and it should just
work.

On Sat, May 26, 2012 at 2:22 PM, Christian Schneider
<chris@die-schneider.net> wrote:
> It is unix specific but on that platform it really might make sense to us=
e
> the user keys and hosts.
> As we need a safe place for at least the private keys I think it makes se=
nse
> to use the user dir for them.
> So we could just use the directory structure that ssh uses.
>
> On windows these directories would not be there but we could still use th=
e
> same structure.
>
> Christian
>
> Am 25.05.2012 22:03, schrieb Guillaume Nodet:
>
>> That's unix specific and we have windows users ...
>>
>> On Fri, May 25, 2012 at 9:13 PM, Ioannis Canellos<iocanel@gmail.com>
>> =A0wrote:
>>>
>>> I may lost some bits, but couldn't we just reuse the users keys and
>>> authorized hosts, instead of creating, adding or removing?
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> FuseSource<http://fusesource.com>
>>>
>>> **
>>> Blog: http://iocanel.blogspot.com
>>> **
>>> Twitter: iocanel
>>> *
>>
>>
>>
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>


--=20
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com