If you have authorization to change access to a server resource, you use the Permissions portlet of My webMethods Server to assign access control to it. For example, if you are the owner of the Engineering folder in the example described in Server Authorization, a wizard in the Permissions portlet allows you to select one or more Principals and Right Sets, and associate them with that folder. For more information on controlling permissions, see Managing Permissions.

You do not have to explicitly grant and deny access for every newly created object. If you give your taxonomy a little forethought, you can keep the potential maintenance burden to a minimum. My webMethods Server employs a method called static propagation of its access rights on server objects when they are created. This means that at creation time, a server resource receives its access rights from its parent resource. If subsequent changes are made to the parent's access rights, these rights are not dynamically updated in the child object. However, you can use the Permissions portlet to cause parent objects to apply access rights explicitly to their children.

To illustrate static propagation and parent-child interaction as it relates to access rights, we will return to the example of the Engineering folder. In that example, the Engineering folder has BRIAN DENY. As the owner of the Engineering folder, a user creates a sub folder called Secret Project. Because of static propagation, the new Secret Project folder has BRIAN DENY at the time of creation. If the owner goes back and changes the permissions of the Engineering Folder to allow Brian access, Brian still does not have access to the Secret Project sub folder.