In this trail, we’ve been examining the HelloWorldProviderSecure
component to understand how it uses a secure connector. In this
lesson we examine how the component descriptor and security policy
are set.
First, let’s examine the component descriptor. This file should
be located at ${OW_HOME}/HelloWorldProviderSecure-1.0/policies/InstallableComponentDescriptorPolicy.xml.
View this file using owediticd.bat/owediticd.csh, or if the Openwings
core is running, run Openwings Explorer, expand the local platform,
right click on HelloWorldProviderSecure-1.0 and select Edit Descriptor.
Scroll down and edit the Resolvable Classpath field:
The first item in the list is the connector. Now select Cancel,
and from the main ICD editor window, edit the Resolvable Codebase
field:
The connector is also specified in the codebase, so remote users
can download the connector classes. Cancel out of this window.
Finally, edit the Properties field in the ICD:
The HelloWorldProviderSecure component specifies its Java security
policy in the Properties field. Note that after component installation,
the original "java.security.policy" property is stored
as "com.gd.openwings.install.originalJavaSecurityPolicy"
so it can be re-resolved every time. The HelloWorldProviderSecure
security policy depends on the Openwings core security policy
and adds a file of permissions specific to its own source code.
This file is located at ${OW_HOME}/HelloWorldProviderSecure-1.0/policies/HelloWorldProviderSecure.policy.
Here are the contents of this file:
// Helloworld Provider - DEFAULT SECURITY POLICY
// USE FOR DEPLOYED SYSTEMS
grant principal net.openwings.security.OpenwingsRole "ow_user"
{
permission net.openwings.security.ServicePermission
"com.gd.openwings.demo.helloworld.service_sync.HelloWorldServiceSynchronous.helloWorld()";
};
The HelloWorldProviderSecure component uses this grant clause
to control who may access the HelloWorldServiceSynchronous service
that it provides. This particular permission grants access to
the helloWorld() method only, to any user who has the "ow_user"
role. Since this is the only method on the interface, it would
be just as simple for the permission target to use the wildcard
character to indicate every method on the interface: "com.gd.openwings.demo.helloworld.service_sync.HelloWorldServiceSynchronous.*".
Note: if you name multiple Openwings roles as principals in a
grant clause, this means that the priviliges named in the clause
are granted to users who have all the named roles. (It's an AND,
not an OR).
// user must have BOTH admin and user roles
grant principal net.openwings.security.OpenwingsRole "ow_user",
principal net.openwings.security.OpenwingsRole "ow_admin"
{ ... }
Therefore in most cases, you should only use a single "principal"
in your grant clauses. If you intend to give the same set of permissions
to each of multiple roles, you'll need a separate grant clause
for each role.
There are a few things that you should consider when creating
and installing your own components using secure connectors. First
of all, your interface will probably have more than just a single
method. Openwings secure connectors do provide per-method access
control, but it can be cumbersome to generate exactly the right
text for the permission. We provide a policy generation tool
that produces the exact syntax for ServicePermissions for each
method of a specified interface. This tool is located at ${OW_HOME}/openwings-1.0/bin/owpolicytool
(it will have a .bat or .csh suffix depending on your platform).
An example execution of the tool would be as follows:
owpolicytool net.openwings.container.Container ow_identity.jar
ow_container.jar
This will generate grant clauses such as those seen
here.
Note that the HelloWorldProviderSecure demo component assumes
the existence of a ow_user role on the target system. This may
or may not be the case (See the Security
Introduction trail to learn more on configuring Openwings
roles.) When you install a component that is using a secure connector,
you may want to go and edit the security policy file so that it
makes sense for the roles on your system. Then you’ll need to
re-resolve the component. Techniques for re-resolving your component
are discussed
here.
Next: Back to Tutorial
Trails
