Java Reference
In-Depth Information
Are you stuck in the past?
The approach we just outlined for using the
ConditionalPermissionAdmin
service
is simplified by the introduction of the
ConditionalPermissionUpdate
API in the
OSGi R4.2 specification. If you're using a framework that implements an older R4
specification, the steps are conceptually the same, but the details are different. For
example, after getting the
ConditionalPermissionAdmin
service, you need to di-
rectly add
AllPermission
for your bundle:
ConditionPermissionInfo myCPI = cpa.addConditionalPermissionInfo(
new ConditionInfo[] {
new ConditionInfo(
BundleLocationCondition.class.getName(),
new String[]{context.getBundle().getLocation()}) },
new PermissionInfo[] {
new PermissionInfo(
AllPermission.class.getName(), "", "") });
You assign permissions to other bundles in a similar fashion. To remove unexpected
or unwanted permission entries, you need to loop through any existing
Condi-
tionalPermissionInfo
objects and delete them, like this:
Enumeration e = cpa.getConditionalPermissionInfos();
while (e.hasMoreElements()) {
ConditionalPermissionInfo info =
(ConditionPermissionInfo) e.nextElement();
if (!info.equals(myCPI)) {
info.delete();
}
}
Notice that in this example, you take care not to delete your own
Conditional-
PermissionInfo
; otherwise, you'd lose the ability to set permissions. This highlights
the most important difference between this older (and deprecated) approach and the
newer update approach: changes happen immediately and don't require any sort of
commit operation.
ALLOW- VS. DENY-ACCESS DECISIONS
Until this point, we've talked about granting permissions to allow code to perform
some operation. This is the standard way to think about permissions in Java. The
OSG
i
R4.2 specification introduced a new wrinkle: deny-access decisions. Instead of only
using permissions to say what code is allowed to do, you can also use them to say what
code isn't allowed to do. You saw the standard case in listing 14.2, where you added a
condition with an access decision of
ConditionalPermissionInfo.ALLOW
; this corre-
sponds to the normal case of saying what is allowed. But now you can use
Condi-
tionalPermissionInfo.DENY
to say what isn't allowed.
Being able to allow/deny permissions makes it possible to use a white list/black list
approach for handling security. Deny-access decisions can significantly simplify some
security policies because they let you easily handle an exception to a general rule.
Consider a case where you want to allow a bundle to import all packages except those
