Hi Andreas,
I agree that this issue ought to be documented. For what it's worth, I'm
close to publishing a white paper on 10.4 security. That paper mentions
this issue. I would like to see Derby's security documentation
overhauled. This is one among many important issues which are either
missing from Derby's documentation or hard to find because the security
topics are scattered about the manuals.
Regards,
-Rick
Andreas Kyrmegalos wrote:
Hello,
just wanted to report an issue I have encountered. I searched JIRA
but I didn't come accross anything relevant. What I did do is read
issue 2196 thoroughly. Not one of the linked issues is related to what
I have encountered.
I 'm using derby 10.4.1.3, specifically the binary release (648379),
on a windows XP machine.
The basic security manager is throwing:
08004:Connection refused : javax.naming.CommunicationException:
192.168.x.x:10389 [Root exception is
java.security.AccessControlException: access denied
(java.net.SocketPermission 192.168.x.x:10389 connect,resolve)]
if ldap is the authentication provider, during system shutdown (and
most likely whenever derby attempts to access the ldap server, haven't
gotten around to that yet). Derby is started as a network server from
the command line (NetworkServerControl start and NetworkServerControl
shutdown are invoked).
A security socket permission has to be enabled for derby.jar that will
allow opening a connection to the ldap server.
Since the default security manager is activated before any access to
the derby.properties file, no fields related to ldap can be passed to
the server.policy file. Allowing derby to connect to any host is
obviously a security risk so such an option should not be considered.
Therefore, I believe it is extremely important that it gets documented
in the Developer's Guide. A suggestion should appear in section /Derby
and Security/Configuring security in a client/server environment/. A
more detailed description of the issue must be documented in section
/Derby and Security/External directory service./ Something along the
lines of,
...
...in order to use derby with an ldap server in a production
environment a custom security policy file has to be deployed that will
allow derby, among other things, to access the ldap server.
Example for a security.policy file. Derby in installed in the
c:\derbyDB directory and the ldap server is located at host
ldap.example.com port 10389.
grant codeBase "file:/c:/derbydb/lib/derby.jar"
{
// This permission is neccesary if ldap is selected as an
authentication provider
permission java.net.SocketPermission "ldap.example.com:10389",
"connect";
...
Andreas
