The "Derby and security" main topic should clarify the authentication/authorization distinction as described by Rick under
DERBY-5522, or should at a minimum point to other topics that make this clear:
1) Authentication determines whether you are a legal user. It establishes your identity.
2) Authorization determines what operations can be performed by you, that is, by your Derby identity.
So far, so good. Those are just generic definitions of authentication and authorization which hold true for lots of software, not just Derby. Now for the tricky bit, which is specific to Derby:
Derby understands two kinds of identity:
A) System-wide identity. Currently, any legal system-wide identity enjoys authorization to perform the following operations:
i) Create databases.
ii) Restore databases.
iii) Shutdown the Derby engine.
B) Database-specific identity. If you are a legal identity in a specific-database, then you may enjoy the following rights:
i) You can connect to that database--provided that coarse-grained connection authorization has not been set to noAccess.
ii) You can shutdown that database, encrypt it, and upgrade it--provided that you are the database owner.
iii) You can create your own SQL objects and write data to your own tables--provided that your coarse-grained connection authorization has not be set to readOnlyAccess.
iv) You can access other SQL objects--provided that the owners have granted you fine-grained SQL access to those objects and provided you have not been limited by coarse-grained readOnlyAccess.