db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: JMX Access Control Proposal
Date Thu, 21 Feb 2008 17:53:26 GMT
John Embretsen wrote:
> Related to DERBY-1387, there is an access control proposal on the wiki at
> http://wiki.apache.org/db-derby/JMXSecurityExpectations#head-0e3b575bde6a9f7dce809605aa153ccff9daa7e7

> The proposal is also related to a previous E-mail thread with the 
> subject "JMX
> meeting system authorization (DERBY-2109 & 1387)",
> http://db.markmail.org/message/s7eqlhz6ydrufatl?q=list:org%2Eapache%2Edb%2Ederby-dev

> I'm starting a new thread here so that we don't deviate too much from "the
> Apache way" on the wiki...
> 1) I noticed that Derby connection authorization (db-authr) is not 
> mentioned in
> the proposal. Does this mean that this will be ignored, at least for JMX 
> actions
> that do not rely on obtaining a regular JDBC connection to the database 
> from the
> MBean?

The proposal is only saying that any JMX action (get/set attribute and 
invoke operation) on any of Derby's MBeans must go through some 
authorization check. Where existing authorization mechanisms exist then 
they will be the ones used, to avoid multiple levels of authorization 
checking and configuring. Thus setting a database attribute requires 
executing a database procedure and thus the user must have been granted 
permission to execute that procedure and have a read-write connection.

If a JMX action does not require obtaining a JDBC connection to the 
database then I would say db-authr is not applicable (which appears 
similar to being ignored). db-authr defines the state of a user's JDBC 
connection into the database (it's now called connection level 
authorization), thus it can only apply if a connection is being obtained.

I'm also assuming that the required expectation is followed at all times 
(from the wiki):

  "A valid JMX user (a user able to connect via JMX to Derby's 
MBeanServer) must not be able to access information or perform 
operations that would otherwise be restricted by Derby's existing 
security mechanisms (authentication, authorization, Security Manager, 

> 2) I'm curious about how this proposal relates to Derby authentication?
> I'm still a bit puzzled here, I guess. 


> My experiments with the client driver and the network server indicate 
> that if
> derby.connection.requireAuthentication is enabled programmatically as a 
> system
> property, and disabled as a database property, and the
> derby.database.propertiesOnly property has not been set, then passing
> system-level authentication is required in order to obtain a client 
> connection.
> Am I misunderstanding something?

I see what you mean now, we are using terminology differently. There are 
two places in the code where authentication checks are made, for the 
system and for the database. The database authentication can be 
configured using database properties or system properties.

I'm using database authentication to mean the check that is invoked at 
the database level (JDBC connection request) regardless of how it is 

You are using the term system authentication to mean the check that is 
invoked at the database level if it is configured using system 
properties (which I agree *may* have the authentication as the system 
one, an application's implementation of authentication could implement 
different checks based upon being system or database).

Either way, I think we agree to connect to a database only a single 
authentication step is required.


View raw message