Rick Hillegas (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561118#action_12561118 ]
Rick Hillegas commented on DERBY-2109:
--------------------------------------
So I think we can agree that a user has a unique identity, can we call this UID? This corresponds to what is stored in the system tables.
I'm afraid that when I read these words, they sound like this to me: "A person has a
unigue identity, a UID, which is stored in the system tables." I don't agree with
this.
> Two persons (Edward and EdWard in my example) end up with the same
identity. The identity is not unique. That's a problem.
Does it help if I say "a *database* user has a unique database identity,
call it DBUID)", because that's a fact of how Derby works and how the
SQL Standard require it works. We can only be concerned about the
identity and its uniqueness & meaning in Derby's realm, database or
system. How a real person maps onto a Derby database or system users is
not relevant here. E.g. Edward and EdWard defining two unique people is
obviously unique only in some specified domain, e.g. a unix system
logins in a corporate setup. Such a setup has to understand how
identities need to be mapped across systems with different rules, e.g.
mapping those unix login names to e-mail addresses would also fail with
a simple use of [EMAIL PROTECTED], since e-mail addresses are
case-insensitive while logins are not.
Currently system users do follow the same rules as database users, thus
there is an equivalent system user unique identifier, call it SYSUID.
In *Java code* I can provide the identifier values you list as follows:
String u1 = "Edward";
String u2 = "EdWard";
String u3 = "\"Edward\"";
String u4 = "\"EdWard\"";
Derby's documented rules state that u1 and u2 are equivalent, thus they
are the same identifier and the CNF of it is EDWARD (SYSUID=EDWARD).
u3 and u4 are two different identifiers (and also different to u1,u2),
thus they allow your two edwards to be distinguished, at the cost of
having to delimit the name with quotes.
If an authentication implementation is ignoring the rules defined for
how Derby handles user names then I'm not sure what can be done. An
application can interface correctly into any authentication scheme by
providing its UserAuthenticator and following the rules Derby indicates.
As I said, I think looking back it was the wrong choice to have pushed
the SQL identifier model into the Java space, but that's how it works
today in Derby's Java code, property files, property key-value pairs.
We could say that within a Java policy file then we follow a simple Java
model, meaning that the user name provided corresponds to the SYSUID.
That might make life clearer in some cases, but now consistency across
apis goes away which may confuse the situation.
I don't see that we have to support case-sensitive usernames in 10.4.
Could you state what you are proposing for 10.4 for system users that
are represented by SystemPrincipals in the policy file? I'm still
somewhat lost as you seem to be saying the system authentication has a
different model to database authentication.
Thanks,
Dan.
