Re: extend user authentication for storing user roles

> Hi Damian,
>
> You may be able to get what you want by doing the following:
>
> 1) Create a table which stores credentials and roles, as you've described
>
> 2) Write a user-defined authenticator, which uses that table in order
> to perform database-side authentication
>
> Plugging in a user-defined authenticator should be easy. You need to
> write a class which implements
> org.apache.derby.authentication.UserAuthenticator. This is described
> in the Developer's Guide:
> http://db.apache.org/derby/docs/10.5/devguide/devguide-single.html#cdevcsecure42374 
> Just scroll down to the section which shows an "Example of setting a
> user-defined class".
>
> Hope this helps,
> -Rick
>
> Damian Hofmann wrote:
>> Hi
>>
>> I'm new to derby an have a question about extending user authentication.
>>
>> I'm developing a multiuser rich client application that connects
>> directly to a derby server. The clients should authenticate
>> themselves via user name and password. Business logic requires, that
>> each user is given a user role. The user role tells the client, what
>> features the user may use and what features aren't permitted. My
>> current idea is, to create a user table with user name, password-hash
>> and user-role. This should work fine for users, that only use the
>> client application.
>>
>> But I think there is a problem with this. The whole
>> authentication-logic only exists in the clients. The server still
>> isn't protected. Anyone with some knowledge about SQL can connect the
>> database server and do anything, ignoring the user permissions
>> completely. From the developers guide I've learned, that derby offers
>> an authentication mechanism to authenticate users to the database
>> system. This should prevent this scenario.
>>
>> I don't know how to best combine derby's user authentication with my
>> user roles table. Is there a way to extend the user authentication in
>> a way, not only user name and password are stored, but also
>> additional data? Or do you see another (better) way to satisfy both
>> requirements? Do I realy have to manage two sets of user data?
>>
>> Thanks for your advise
>> Damian
>>
>>
>