Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Integration Server Administrator's Guide | Controlling Access to Resources | Controlling Access to Resources with ACLs | Default Settings and Inheritance
 
Default Settings and Inheritance
 
What Happens When You Change Existing ACL Assignments
This section describes the default settings for newly created packages, folders, and other elements and how a folder's ACL assignments affect the elements it contains. For example, if you create a service and don't explicitly assign any ACLs to it, what does the server use for that service's ACL assignments? In general, it works as follows:
*When you create a package, the server assigns Default for the List ACL. (Packages do not have Read, Write, or Execute ACLs). This means that any authenticated user can see that the package exists.
*When you create a top-level folder, that is, one that is not contained in another folder, the server assigns Default for the List, Read, and Write ACLs, and Internal for the Execute ACL to the folder. This means that any authenticated user can see that the folder exists. The Read and Execute ACLs have no meaning for the folder itself. They are there just for inheritance purposes. In other words, elements in the folder will inherit those settings.
*When you create a subfolder or other element (service, schema, specification, document type, trigger, and other elements) the folder or other element inherits its ACL setting from the parent folder.
This behavior is summarized in the following table:
ACL assigned by default
Element Type
List
Read
Write
Execute
Package
Default
N/A
N/A
N/A
Top-Level Folder
Default
Default
Default
Internal
Subfolder
Inherit
Inherit
Inherit
Inherit
Other Element
Inherit
Inherit
Inherit
Inherit