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.