*** (LS) Thank you Mamta. This is very helpful. I don't think that the Derby docs do a good job of describing the difference between user authentication and user authorization, and I will update the draft text that I posted for grant/revoke to make it more clear what the different properties do. Thanks! Laura
On 8/2/06, Mamta A. Satoor (JIRA) <[email protected]> wrote:
[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12425162 ] Mamta A. Satoor commented on DERBY-1330: ---------------------------------------- Laura, here are my attempts at your questions. derby.connection.requireAuthentication is a pre 10.2 property which enables user authentication. This property will require that a user name and password is supplied at database connection time. Chances are that in a multi-user environment, Derby would be run with authentication enabled (more info can be found in our existing docs in the Security->Derby and Security -> Working with user authentication -> Enabling user authentication section) derby.connection.requireAuthentication will ensures that a user with valid user name and password will be allowed to connect to Derby. A multi-user environment might also want to control what actions are allowed by different users once they are connected to Derby. This part falls under User authorization. More on this can be found under Security->Derby and Security -> User authorization -> Setting user authorization Prior to Derby 10.2, you could use derby.database.defaultConnectionMode to specify the default access mode to be noAccess, readOnlyAccess and fullAccess. There was no support for Grant/Revoke pre 10.2. With Derby 10.2, we are introducing grant revoke which is another scheme of user authorization and it is enabled by the property derby.database.sqlAuthorization. When you set this property to true, Derby is said to be running in Derby SQL Standard Authorization mode. So, in short, property derby.database.sqlAuthorization allows the grant revoke feature. There has been some talk about not requiring property property derby.database.sqlAuthorization and enabling grant revoke when user attempts to use grant/revoke sql statements for the first time. Someone more knowledgable about that discussion might want to add their comments here. So, I hope I have not gotten you confused with all the jargons. Existing manuals might be helpful in clearing out confusion on authentication vs authorization. If you have any further questions, feel free to post them, > Provide runtime privilege checking for grant/revoke functionality > ----------------------------------------------------------------- > > Key: DERBY-1330 > URL: http://issues.apache.org/jira/browse/DERBY-1330 > Project: Derby > Issue Type: Sub-task > Components: SQL > Affects Versions: 10.2.0.0 > Reporter: Mamta A. Satoor > Assigned To: Mamta A. Satoor > Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, AuthorizationModelForDerbySQLStandardAuthorizationV2.html, DERBY1330javaDocWarningsDiffV9.txt, DERBY1330javaDocWarningsStatV9.txt, Derby1330MinorCleanupV7diff.txt, Derby1330MinorCleanupV7stat.txt, Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330setUUIDinDataDictionaryV10diff.txt, Derby1330setUUIDinDataDictionaryV10stat.txt, Derby1330setUUIDinDataDictionaryV8diff.txt, Derby1330setUUIDinDataDictionaryV8stat.txt, Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330uuidIndexForPermsSystemTablesV4stat.txt, Derby1330uuidIndexForPermsSystemTablesV5diff.txt, Derby1330uuidIndexForPermsSystemTablesV5stat.txt, Derby1330uuidIndexForPermsSystemTablesV6diff.txt, Derby1330uuidIndexForPermsSystemTablesV6stat.txt, Derby1330ViewPrivilegeCollectionV1diff.txt, Derby1330ViewPrivilegeCollectionV1stat.txt > > > Additional work needs to be done for grant/revoke to make sure that only users with required privileges can access various database objects. In order to do that, first we need to collect the privilege requirements for various database objects and store them in SYS.SYSREQUIREDPERM. Once we have this information then when a user tries to access an object, the required SYS.SYSREQUIREDPERM privileges for the object will be checked against the user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS. The database object access will succeed only if the user has the necessary privileges. > SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't have any information in it at this point and hence no runtime privilege checking is getting done at this point. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
-- Laura Stewart
