Java Reference
In-Depth Information
14.4
Managing permissions with Conditional Permission Admin
Until now, we've talked mostly about the details of permissions (what they look like
and what they mean) and otherwise glossed over how you grant permissions to bun-
dles. Individual permissions in and of themselves aren't that useful. The useful part is
being able to grant and manage permissions for groups of bundles in accordance with
your desired security policies. To help you achieve this goal, the
OSG
i specification
defines the Conditional Permission Admin Service.
Whereas standard Java offers a file-based policy approach for permission manage-
ment,
OSG
i only defines an
API
-based approach, because it fits better with the inher-
ently dynamic nature of the
OSG
i environment. The Conditional Permission Admin
Service is the one place to go to define and maintain your security policy. Further, it
introduces a new way of performing permission management by defining the concept
of
conditional
permission management, which is how it got its name. Let's explore this
concept first.
14.4.1
Conditional permissions
If you're at all familiar with standard Java permission management, you know that the
basic approach is to grant permissions to code using a policy file. A standard Java pol-
icy file may look something like this:
grant signedBy "sysadmin" {
permission java.security.AllPermission;
};
grant codeBase "file:/app/main.jar" {
permission java.security.AllPermission;
};
grant {
permission java.io.FilePermission "/tmp/*", "read,write";
};
In this policy file, you granted all permissions to classes signed by
sysadmin
and from
file:/app/main.jar. All other classes are only granted read/write access to the /tmp/
directory. Although this example assigns only a single permission for each case, you can
assign any number of permissions in a single group. When the security manager walks
up the call stack to check permissions at execution time, the permissions for a given
class are determined by effectively using either its signer or code base as a key to look
up the associated protection domain to see which permissions have been granted to it.
If the protection domain has the permission, the call can proceed; if not, the call fails.
This approach works, but it's somewhat simplistic. In particular, it allows you to
grant permissions only based on one of two conditions:
Who cryptographically signed the class
■
The originating location of the class (that is, the code base)
■
The Conditional Permission Admin Service improves on this by introducing an
abstract condition concept, which allows you to grant permissions based on arbitrary
conditions. A condition acts as a Boolean guard that determines whether a permission
