[
https://issues.apache.org/jira/browse/DERBY-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278048#comment-13278048
]
Rick Hillegas commented on DERBY-5548:
--------------------------------------
Here is a more flexible proposal. The idea is to let applications use any
authentication scheme they want (including LDAP) and still let them...
1) Code their own rules for authorizing system-wide operations...
2) or use a Derby-supplied NATIVE scheme which administers system-wide
permissions via GRANT/REVOKE.
A sketch of this scheme follows.
----- (1) APPLICATION-SUPPLIED AUTHORIZATION CODE --------------
We expose the following interface in org.apache.derby.security:
public interface OperationAuthorizer
{
// system-wide operations
public static final int CREATE_DATABASE = 0; // includes ability to
restore databases
public static final int SHUTDOWN_ENGINE = 1;
public static final int ADMINISTER_NETWORK_SERVER = 2; // includes
ability to start and stop the network server and toggle tracing
/** Returns true if the user is authorized to perform the operation */
public boolean isAuthorized
(
int operation,
String userName
)
throws SQLException;
}
We introduce a new Derby property...
derby.system.authorizer
...which may take the following values:
i) NONE: (this is the default value, which installs an OperationAuthorizer
allowing all users to perform all system-wide operations).
ii) The name of an application-supplied class which implements
OperationAuthorizer.
iii) NATIVE:$authorizationDB (this forwards authorization requests to the
$authorizationDB as described below).
----- (2) NATIVE AUTHORIZATION --------------
We introduce a new value for SYSPERMS.OBJECTTYPE:
DERBY
We introduce the following new values for SYSPERMS.PERMISSIONS:
CREATE_DATABASE
SHUTDOWN_ENGINE
ADMINISTER_NETWORK_SERVER
Then the DBO in a database can issue commands like this:
grant create_database on derby to dbo_role;
grant shutdown_engine on derby to sysadmin_role;
By default, a DBO is granted all system-wide permissions.
We introduce the following vti, which returns a ResultSet having the shape of
SYSPERMS. This vti returns all SYSPERMS permissions which have been granted to
the given grantee or to a role which the grantee can set:
syscs_diag.perms_closure( grantee varchar( 128 ) ) ...
When derby.system.authorizer=NATIVE:$authorizationDB is set and a user attempts
a system-wide operation, the NATIVE authorization service does the following:
1) Connects to $authorizationDB using the user's supplied credentials.
2) Runs the following query in the resulting connection. Here ? is stuffed with
the permission we're looking for (e.g., CREATE_DATABASE):
select count(*) from table ( syscs_diag.perms_closure( current_user ) ) t
where t.permission = ?;
3) If the query result is non-zero, then the system-wide operation is allowed.
> Implement a GRANT/REVOKE scheme for authorizing system-wide operations
> ----------------------------------------------------------------------
>
> Key: DERBY-5548
> URL: https://issues.apache.org/jira/browse/DERBY-5548
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
>
> This is an alternative proposal for how we could authorize system-wide
> operations. Those operations are:
> o Database creation
> o Database restoration
> o Engine shutdown
> o Server shutdown
> o Server startup
> Currently, any valid Derby user can execute all of those operations. This
> leaves Derby-powered applications vulnerable to resource-exhaustion and
> denial-of-service attacks. There is no reason that a data-entry clerk should
> have the power to bring down an enterprise-wide application.
> DERBY-2109 describes our first attempt to implement authorization for
> system-wide operations. The work on that issue was never completed. Under the
> DERBY-2109 scheme, system-wide operations are authorized by entries in the
> application's Java security policy. That scheme has some shortcomings:
> 1) Configuring Java security policy files is tricky. It is easy to make
> mistakes. Furthermore, the policy file reader does not give you much
> assistance in tracking down and correcting those mistakes.
> 2) The scheme only grants privileges to individual users. You can't grant
> system-wide privileges to roles.
> The following alternative scheme builds on the idea of a Credentials DB,
> introduced by the work on DERBY-866. Thanks to Dag for helping puzzle through
> these issues.
> -------------------------------------------------
> A system-wide Credentials DB could be used to store system-wide privileges in
> addition to system-wide credentials. 2 variants of this proposal have been
> considered:
> i) We could introduce some new privileges, extensions to the SQL Standard
> privilege set. The DBO of the Credentials DB could grant and revoke these
> privileges to/from users/roles:
> DERBY_CREATE_DATABASE
> DERBY_RESTORE_DATABASE
> DERBY_SHUTDOWN_ENGINE
> DERBY_SHUTDOWN_SERVER
> DERBY_STARTUP_SERVER
> ii) Alternatively, we could introduce some new system routines to represent
> the system-wide operations. Privilege to perform the operations would depend
> on whether a user/role had been granted EXECUTE privilege on the
> corresponding routines:
> syscs_util.syscs_create_database()
> syscs_util.syscs_restore_database()
> syscs_util.syscs_shutdown_engine()
> syscs_util.syscs_shutdown_server()
> syscs_util.syscs_startup_server()
> A new Derby property would configure whether this authorization scheme should
> be used. This property would be set at the system level, that is, on the JVM
> properties or in derby.properties:
> -Dderby.system.authorization=NATIVE
> If we implemented this scheme in the 10.9 timeframe, then we could default it
> to being on whenever NATIVE authentication was on at the system level. For
> instance, for an application with one database, myDB, NATIVE authentication
> and authorization would both be switched on by setting one knob:
> -Dderby.authentication.provider=NATIVE:myDB
> We could also introduce a new attribute on the connection URL:
> role=roleName
> Here for instance would be the processing flow when a user tried to connect
> with the following URL:
> jdbc:derby:;shutdown=true;user=alice;password=alicepassword;role=sysadmin
> a) A connection would be opened to the Credentials DB using alice's
> credentials.
> b) On that connection, an attempt would be made to "set role sysadmin". If
> that failed, the shutdown would error out.
> c) If the role change succeeded, Derby would verify whether alice or the
> sysadmin role had been granted privilege to shutdown the engine. If not, the
> shutdown would error out.
> d) If the privilege had been granted, then orderly shutdown would be
> performed.
> It should be possible to make this authorization scheme work regardless of
> the authentication scheme being used. That is, it could work regardless of
> whether you were using LDAP, custom, or NATIVE authentication.
> A key advantage of this scheme is that it would be easy to administer using
> familiar GRANT/REVOKE commands.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
