Project

General

Profile

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.

Press the Add ACL button. A dialog box will be displayed:

In the 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 1700 and 1800.

In the 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 .java or .class) in this name. If the interface being exported is an inner class, the fully qualified class name might look something like this: com.acme.corp.something.SomeOther$ExportedApiName.

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:

Select read and execute as the permissions. Both are necessary to make API calls. write and denied should be left unchecked. Press the Save button.

The Add ACL item dialog will now look something like this:

Press the 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.