I am also focusing on ease of use and you are right ease of use is a key
enabler for success of Karaf.
So how about having the default private key but having it disabled by
default.
For example we could have a hash before the key in the keys.properties
or have a switch in config.properties that is turned off by default.
So it is really easy to enable the feature but still the default is secure.
About the integration with the OS ssh I am also not sure if it is good
or not. In some cases it may be wanted in others not.
Christian
Am 26.05.2012 15:32, schrieb Guillaume Nodet:
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.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
