The OSGi Security Manager allows you to secure your applications by utilizing the built in Java Security Manager and Java's permission system. This does not provide security in the sense that a lot of people tend to think of it: authentication, authorization, etc. The Security Manager allows you to assign/revoke permissions to/from code with a policy.
...
You can also opt to use a custom SecurityManager class by dropping in the standard Java system property instead of using this OSGi specific property. You cannot use both properties at the same time. Adding the Java system property will have the same effect as the above property, except that it will use your custom SecurityManager implmentation, for example:
java.security.manager=net.sourceforge.prograde.sm.ProGradeJSM
You then must add an "all policy" that will allow all of the non-OSGi code to execute with all privileges:
...
Once a ConditionalPermissionUpdate has been committed to the service, it will register those permissions with the OSGi security manager and it will begin granting or denying permissions and you might see some permission checks fail in your log with a stack trace. Unfortunately, that stack trace is completely worthless, because it doesn't take into account the protection domains for the bundles, which is really all that matters. There are a couple of options at this point to figure out what bundles need what permissions. You can drop a breakpoint in the AccessControlContext.checkPermission(...) method (this is a base Java class) on the "throw new AccessControlException..." line, or you can use the custom debugger that was developed for DDF: https://github.com/coyotesqrlcodice/acdebugger (this will most likely get contributed to Codice soon, so watch for an updated binary version that we package with DDF itself).
...
| Page Properties | ||
|---|---|---|
| ||
|