db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: NATIVE authentication
Date Tue, 21 Aug 2012 12:56:43 GMT
On 8/20/12 1:07 PM, Thomas Hill wrote:
> Hi,
>
> I am trying create a database from scratch using the new native
> authentication provider introduced with version 10.9.1.0.
> What I tried after reading the docs was:
> 1st attempt) started the network server supplying
> -Dderby.authentication.provider=NATIVE:myCredDB as property
> passed on JVM command line.
> The server started up, but when trying to connect
> I am getting SQLState 4251I "Authentication cannot be performed
> because the credentials database '<databaseName>' does not exist."
> so my assumption the credentials database would be automatically
> created doesn't seem to be correct.
> 2nd attemtpt: started the network server without specifying an
> authentication provider and used ij to connect to server and
> created a database myCredDB manually.
> Shutdown the server and started it up again pointing at this
> manually created credentials database and tried to create an
> application database myAppDB.
> Trying to do this I am getting authentication not possible /
> invalid user. In both connection strings have I used the
> same user (dbo) and password (derby).
> Can someone please support and point me into the right direction
> or potentially share a sample script that shows how to create an
> application database which makes use of native authentication?
>
> Thanks a lot in advance
> Thomas
>
>
Hi Thomas,

I hope that Dag's response got you unstuck A little more context may help:

When you specify

   -Dderby.authentication.provider=NATIVE:myCredDB

you are telling Derby that all connection requests should be 
authenticated using credentials stored in myCredDB. This includes 
requests to create new databases and requests to connect to existing 
databases. Normally myCredDB has to exist before you can connect to any 
database.

There is one exception, however, and this may be what was confusing you. 
If the very first connection request is a request to create the 
credentials database itself (myCredDB), then Derby behaves as follows:

o Derby creates myCredDB

o Derby stores the supplied credentials in myCredDB as the credentials 
of the god-like system administrator.

What you did was slightly different, but the difference is important. 
You tried to create an ordinary database, not the credentials database, 
and it seems as though you were hoping that the supplied credentials 
would be used to automatically create a new user. I can see that that 
behavior would be useful. However, it would defeat the purpose of using 
myCredDB to decide who is allowed to create databases in the first 
place. Once the credentials database exists, only its users have the 
power to create databases.

Keep asking questions if this feature is still confusing. Your feedback 
will help us improve our documentation for this new feature. It would be 
very helpful to us if you could tell us, in your own words, what extra 
advice would help bridge the gap between what the docs say and what you 
understood. That will help us fix the docs so that other users won't 
have this frustrating experience.

Thanks,
-Rick

Mime
View raw message