You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by si...@insession.com on 2005/01/31 00:09:21 UTC
Securing the Derby Network Server in Geronimo - related to GERONIMO-342
Derby's DRDA (Distributed Relational Database Architecture) Network Server
by default only listens for connections on the loopback address (which is
a good default) and does not have authentication turned on.
Therefore on a multiuser O/S this level of security seems inadequate as
any user on the localhost could connect to it using the DB2 Universal
Connector (specifying any userid and password as it will be ignored by the
server) and start creating databases/tables etc.
Q1. Are there any plans on how a default Geronimo configuration would
secure the embedded Derby Network Server?
Q2. What would be the best way to restrict the remote IP addresses that
Derby will accept connections from (e.g. particular IP addresses)? Should
a policy file be used and passed to the JVM when starting Geronimo (see
http://incubator.apache.org/derby/manuals/admin/hubprnt30.html ) or is
there a better way for Geronimo?
Q3. Should we have some simple authentication enabled by shipping a sample
geronimo\var\derby\derby.properties file that has something like the
following?
#
#Security settings
#
derby.connection.requireAuthentication=true
derby.authentication.provider=BUILTIN
#
# User and password list for Derby BUILTIN authentication provider
#
derby.user.system=manager
derby.user.myapp=myapppswd
Thanks,
John
Re: Securing the Derby Network Server in Geronimo - related to GERONIMO-342
Posted by si...@insession.com.
Jeremy Boynes <jb...@apache.org> wrote on 31/01/2005 10:33:58 AM:
> sissonj@insession.com wrote:
> > Derby's DRDA (Distributed Relational Database Architecture) Network
Server
> >
> > by default only listens for connections on the loopback address (which
is
> > a good default) and does not have authentication turned on.
> >
> > Therefore on a multiuser O/S this level of security seems inadequate
as
> > any user on the localhost could connect to it using the DB2 Universal
> > Connector (specifying any userid and password as it will be ignored by
the
> >
> > server) and start creating databases/tables etc.
> >
>
> Hmm - I thought that a username and password had to be supplied for a
> network connection.
Yes, the IBM JCC driver forces you to specify a userid and password, but
the username and password is only validated on the server if
authentication is turned on. By default authentication is turned off.
Also the username is used as the current schema for the connection. See:
http://incubator.apache.org/derby/manuals/develop/develop97.html
Also for authorization, by default users are given read/write access
(fullAccess) :
http://incubator.apache.org/derby/manuals/develop/develop109.html
John
>
> > Q1. Are there any plans on how a default Geronimo configuration would
> > secure the embedded Derby Network Server?
> >
>
> At the moment we are relying on Derby database security. Ultimately I
> hope to integrate that into the JACC authentication providers used by
> the rest of the container, and have a dream at some point of integrating
> Derby's authorization with the JACC policy provider.
>
> > Q2. What would be the best way to restrict the remote IP addresses
that
> > Derby will accept connections from (e.g. particular IP addresses)?
Should
> >
> > a policy file be used and passed to the JVM when starting Geronimo
(see
> > http://incubator.apache.org/derby/manuals/admin/hubprnt30.html ) or is
> > there a better way for Geronimo?
> >
>
> I haven't looked at that.
>
> > Q3. Should we have some simple authentication enabled by shipping a
sample
> >
> > geronimo\var\derby\derby.properties file that has something like the
> > following?
> >
> > #
> > #Security settings
> > #
> > derby.connection.requireAuthentication=true
> > derby.authentication.provider=BUILTIN
> > #
> > # User and password list for Derby BUILTIN authentication provider
> > #
> > derby.user.system=manager
> > derby.user.myapp=myapppswd
> >
>
> I would prefer not to and at least integrate with the user/password
> realm we use for securing JMX remoting - that would mean in the default
> case the usernames/passwords would be the same. Of course, an admin
> could also set up a separate realm for the database.
>
> --
> Jeremy
>
Re: Securing the Derby Network Server in Geronimo - related to GERONIMO-342
Posted by Jeremy Boynes <jb...@apache.org>.
sissonj@insession.com wrote:
> Derby's DRDA (Distributed Relational Database Architecture) Network Server
>
> by default only listens for connections on the loopback address (which is
> a good default) and does not have authentication turned on.
>
> Therefore on a multiuser O/S this level of security seems inadequate as
> any user on the localhost could connect to it using the DB2 Universal
> Connector (specifying any userid and password as it will be ignored by the
>
> server) and start creating databases/tables etc.
>
Hmm - I thought that a username and password had to be supplied for a
network connection.
> Q1. Are there any plans on how a default Geronimo configuration would
> secure the embedded Derby Network Server?
>
At the moment we are relying on Derby database security. Ultimately I
hope to integrate that into the JACC authentication providers used by
the rest of the container, and have a dream at some point of integrating
Derby's authorization with the JACC policy provider.
> Q2. What would be the best way to restrict the remote IP addresses that
> Derby will accept connections from (e.g. particular IP addresses)? Should
>
> a policy file be used and passed to the JVM when starting Geronimo (see
> http://incubator.apache.org/derby/manuals/admin/hubprnt30.html ) or is
> there a better way for Geronimo?
>
I haven't looked at that.
> Q3. Should we have some simple authentication enabled by shipping a sample
>
> geronimo\var\derby\derby.properties file that has something like the
> following?
>
> #
> #Security settings
> #
> derby.connection.requireAuthentication=true
> derby.authentication.provider=BUILTIN
> #
> # User and password list for Derby BUILTIN authentication provider
> #
> derby.user.system=manager
> derby.user.myapp=myapppswd
>
I would prefer not to and at least integrate with the user/password
realm we use for securing JMX remoting - that would mean in the default
case the usernames/passwords would be the same. Of course, an admin
could also set up a separate realm for the database.
--
Jeremy