Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1725896631.1246372187626.JavaMail.jira@brutus>
Date: Tue, 30 Jun 2009 07:29:47 -0700 (PDT)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3282) Add a mechanism for managing users in
 Derby
In-Reply-To: <12635702.1197907123176.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dag H. Wanvik updated DERBY-3282:
---------------------------------

    Component/s: Services

> Add a mechanism for managing users in Derby
> -------------------------------------------
>
>                 Key: DERBY-3282
>                 URL: https://issues.apache.org/jira/browse/DERBY-3282
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>            Reporter: Rick Hillegas
>
> Currently, managing users in Derby is awkward. The BUILTIN mechanism seems appropriate for testing purposes, but has problems in a production setting. DERBY-866 describes part of a new mechanism for managing users. DERBY-866 may be part of the right solution--or it may not be. I think it would be worthwhile to step back from this issue and first describe at a high level what the customer experience should be.  By introducing a  new mechanism, we have the opportunity to think through the complete experience of user management. Here are my initial thoughts:
> 1) This mechanism is mutually exclusive with the currently supported settings of the derby.authentication.provider property.
> 2) There should be a super user who has the power to create, view, and drop users, including database owners. The design should let this super user delegate these powers to other users.
> 3) In the new mechanism it is sufficient that user credentials are system-wide.
> 4) Database owners should nevertheless have the power to state which usernames can connect to their databases. DBOs should also have the power to state who can shut down their databases. This mechanism should be extensible to managing other database-specific powers which fall outside the SQL spec. The design should let the DBO delegate these powers to other users.
> 5) Users should be able to change their own credentials whenever they want.
> 6) No password needed for this mechanism should be stored in plaintext anywhere on the system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.