Java Reference
In-Depth Information
+ context.getBundle().getLocation() + "\"]"
+ "(java.security.AllPermission \"*\" \"*\")"
+ "} \"Management Agent Policy\"");
ConditionalPermissionAdmin cpa =
getConditionalPermissionAdmin(context);
ConditionalPermissionUpdate u = cpa.newConditionalPermissionUpdate();
List infos = u.getConditionalPermissionInfos();
infos.clear();
for (String encodedInfo : encodedInfos) {
infos.add(cpa.newConditionalPermissionInfo(encodedInfo));
}
if (!u.commit()) {
throw new ConcurrentModificationException(
"Permissions changed during update");
}
}
This method combines most of your knowledge about the
ConditionalPermission-
Admin
service. You get the policy file, which defaults to a file called
security.policy
but can be configured. Next, you read in the encodings of the
ConditionalPermis-
sionInfo
objects contained in the policy file and add an encoding for an
AllPermis-
sion
at the beginning of the list for the policy-file reader bundle. The previous step is
necessary to make sure the policy-reader bundle has sufficient permission to make
future changes to the security policy.
After this, you get the
ConditionalPermissionAdmin
service, create a new
Condi-
tionalPermissionUpdate
, and use it to get the current list of
ConditionalPermis-
sionInfo
objects. You clear the existing policy to make sure you're starting with a
clean slate, and then loop through the encoded permissions to decode them and add
them to your list of objects. The only thing left to do is commit the update. Because
the update may fail if the permissions were changed concurrently, you throw an
exception in this case.
To see the full details of this bundle, go to the chapter14/combined-example/
org.foo.policy/ directory of the topic's companion code. This bundle is generic and
can be used in any security-enabled framework to put a policy file into effect. You'll
see it in action a little later when we show a complete example with digitally signed
bundles and a custom condition. We'll introduce bundle signing next.
14.5
Digitally signed bundles
Defining a security policy by assigning permissions to bundles is a workable approach,
but being able to step up a level can simplify things. For example, you may trust a par-
ticular provider, so it's nice to be able to assign permissions based on the provider
rather than individual bundles. Doing so simplifies defining a security policy, because
it raises the level of abstraction. Digitally signed bundles can help you achieve this;
specifically, they help you do two things:
Authenticate the provider of a bundle
■
Ensure that bundle content hasn't been modified
■
