db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3335) Allow UserAuthenticator.authenticateUser to work with authorization identifiers and not user name.
Date Mon, 21 Jan 2008 19:24:34 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561103#action_12561103

Daniel John Debrunner commented on DERBY-3335:

An alternate way of addressing this would be to not add a new method or change the meaning
of the existing parameters.

Instead Derby could add a property to info Properties set passed into authenticateUser.
This property would be the unique user identity (which is currently described as authorization
identifier) but the discussion in DERBY-2109 might come up with a better name since authorization
identifier has a specific meaning in SQL and a different meaning in the derby docs).

E.g. the property could be sql.user and thus

userName=Fred  => sql.user=FRED
userName=Fred  => sql.user=FRED
userName="Fred" => sql.user=Fred

Minor backwards compat risk that a user authentication scheme was using sql.user to pass some
information to its specific scheme.

> Allow UserAuthenticator.authenticateUser to work with authorization identifiers and not
user name.
> --------------------------------------------------------------------------------------------------
>                 Key: DERBY-3335
>                 URL: https://issues.apache.org/jira/browse/DERBY-3335
>             Project: Derby
>          Issue Type: Improvement
>          Components: Security
>            Reporter: Daniel John Debrunner
>            Priority: Minor
> Add a new method to UserAuthenticator that allows the authentication scheme to request
that the user name passed into authenticateUser is an authentication identifier. This would
absolve authentication schemes from each implementing the mapping from user name to authorization
identifier. Implementing the logic in each scheme is pointless and subject to errors if a
different set of rules is implemented by the scheme (say by a coding bug).
> Signature could be
> /**
>   Return true if the identifier argument to authenticateUser is to represent an authorization
>    false if it is to represent the user name.
>    Note the identifier argument passed into authenticateUser  is provided by the database
>    @since 10.x  If this method does exist then a return of false is assumed.
> */
> public boolean authenticateUsingAuthorizationId();
> The first argument to authenticateUser would change for userName to identifier with appropriate
comment changes.

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

View raw message