Adding a NET Resource ACL¶
From the main menu of the administration client, use the
Access Control → Show by Resource Type → net to get to the list of net resource ACLs:
This will bring up a screen with a table of all net ACLs and buttons for possible actions:
The ACL can be inserted anywhere, but a good location is just before the “system:authenticate” entry which has an ID of
1800 (in this example). The ACL just before it is
1700. Make a note of these two IDs.
Add ACL button. A dialog box will be displayed:
Access Control ID field, enter a number halfway in between the two IDs previously noted (
1750 in this example). This will place the new ACL in between the two ACLs with IDs of
Resource Instance Name field, enter the fully qualified package and class name of the interface being exported:
com.acme.corp.something.SomeQueue in this example. Do NOT include any suffix (such as
.class) in this name. If the interface being exported is an inner class, the fully qualified class name might look something like this:
Double-click on the
Subjects field (on the actual entry-field, not on the “Subjects” label). This will bring up an additional dialog box named
Change Associated Subjects. Select the accounts to be allowed access to the API on the left side list. If all accounts should have access, immediately press the
Save button. This will leave the field with the text “all_others”. Even though that is what was originally shown there, if it was not edited, the real subject associated with that ACL would have been the server account (
p2jsrv in this example). That is why the dialog box must be brought up and then saved. If a specific list of accounts is necessary (instead of everyone), uncheck the
Associate All Accounts checkbox which is in the top left corner. Select the accounts from the list on the left side (the
Available Accounts), holding down the
CTRL key if there is more than one to select at the same time. Then press the
Add Selected Accounts button to add those accounts to the list on the right. When the right side list (the
Associated Accounts) is complete, press the
Save button at the bottom of the dialog.
Double-click in the
Rights field (the entry-field itself, not the “Rights” label). This will bring up the following dialog:
execute as the permissions. Both are necessary to make API calls.
denied should be left unchecked. Press the
Add ACL item dialog will now look something like this:
Save button. The ACL will have been added to the list if there were no errors. Otherwise, resolve the errors and try again. The ACL list should appear like this:
To ensure force the FWD server to honor the changes immediately, select
Target → Refresh from the menus:
The ACL should be available now.
Log Off and exit the administration interface.
The result will be an edit to the directory file that looks similar to this:
<node class="container" name="001750"> <node class="resource" name="resource-instance"> <node-attribute name="reference" value="com.acme.corp.something.SomeQueue"/> <node-attribute name="reftype" value="TRUE"/> </node> <node class="netRights" name="rights"> <node-attribute name="permissions" value="'0101'B"/> </node> <node class="strings" name="subjects"> <node-attribute name="values" value="developers"/> </node> </node>
This new section will be located inside the
/security/acl/net path in the FWD server's directory file. The directory is an XML file format with a file name that is specific to the server being run. Consult the FWD Runtime Installation, Configuration and Administration Guide for details. It can appear anywhere inside that element in the XML file.
Directly editing the XML file is the alternate approach to making this change. Make sure that this is done when the server is not running! Follow the same guidelines as in the above description for choosing the values such as the
ID (also known as the ACL “name”) to be used. The
ID or name is normally a 6-digit zero padded integer value. It should never be duplicated within the
net ACL section (it must be unique inside the
net element in the XML). If the direct editing method is used, the new configuration will be honored the next time the server starts.
The key to all of this is that the new ACL configures the
net resource to allow a specific list of subjects a particular set of permissions (“rights”) for a specific set of exported APIs.
Don't make the mistake of using the implementing class name for the
Resource Instance Name. In the example above, it would be an error to specify
com.acme.corp.something.server.SomeServer since that is not the interface class name. Whatever class defines the interface you are exporting must be used both in the ACL as the
Resource Instance Name and in the
RemoteObject.obtainNetworkInstance() on the client (see the section below entitled Accessing Services. The client just gets a local proxy that represents the interface and which redirects any calls to the server. Only the server knows the specific class name of the implementation, the client has no idea what implementation class is used on the server. They rendezvous based on the interface name and its contained method signatures.
© 2004-2017 Golden Code Development Corporation. ALL RIGHTS RESERVED.