More DBA job interview questions and answers at
http://dba.fyicenter.com/Interview-Questions/
(Continued from previous question...)
Authorization Identifiers, User Authentication, and User Authorization
When working with both user authentication and user authorization, you need to understand how user names are treated by each system. If an external authentication system is used, the conversion of the user's name to an authorization identifier does not happen until after authentication has occurred but before user authorization. Imagine, for example, a user named Fred.
* Within the user authentication system, Fred is known as FRed. Your external user authorization service is case-sensitive, so Fred must always type his name that way.
Connection conn = DriverManager.getConnection(
"jdbc:derby:myDB", "FRed", "flintstone");
* Within the Derby user authorization system, Fred becomes a case-insensitive authorization identifier. Fred is known as FRED.
* When specifying which users are authorized to access the accounting database, you must list Fred's authorization identifier, FRED (which you can type as FRED, FREd, or fred, since the system automatically converts it to all-uppercase).
derby.fullAccessUsers=sa,FRED,mary
Let's take a second example, where Fred has a slightly different name within the user authentication system.
* Within the user authentication system, Fred is known as Fred!. You must now put double quotes around the name, because it is not a valid SQL92Identifier. (Derby knows to remove the double quotes when passing the name to the external authentication system.)
Connection conn = DriverManager.getConnection(
"jdbc:derby:myDB", "\"Fred!\"", "flintstone");
* Within the Derby user authorization system, Fred becomes a case-sensitive authorization identifier. Fred is known as Fred!.
* When specifying which users are authorized to access the accounting database, you must list Fred's authorization identifier, "Fred!" (which you must always delimit with double quotation marks).
derby.fullAccessUsers=sa,"Fred!",manager
As shown in the first example, your external authentication system may be case-sensitive, whereas the authorization identifier within Derby may not be. If your authentication system allows two distinct users whose names differ by case, delimit all user names within the connection request to make all user names case-sensitive within the Derby system. In addition, you must also delimit user names that do not conform to SQL92Identifier rules with double quotes.
_break
Requirements for Derby Encryption
Derby supports disk encryption, but you must supply the following:
* An implementation of the Java Cryptographic Extension (JCE) package version 1.2.1 or higher.
Derby does not support earlier, non-exportable, versions of JCE (such as JCE 1.2). More information on JCE 1.2.1, including a product download, can be found at: http://java.sun.com/products/jce/index.html.
Any attempt to create or access an encrypted database without the libraries for an implementation of JCE of the proper version, or without Java(TM) 2 Platform, Standard Edition, v 1.2 (J2SE) or higher, raises an exception; you will not be able to create or boot the database.
Note:
The JCE installation documentation describes configuring (registering) the JCE software. You do not need to do this; Derby registers JCE dynamically.
* the encryption provider
An encryption provider implements the Java cryptography concepts. The JRE for J2SE 1.4 or J2EE 1.4 includes JCE and one or more default encryption providers.
(Continued on next question...)
