Now that you have a background in the concepts of making an authorization decision, you can see how access is actually determined at run time. When a server resource is requested, the server evaluates the ACL associated with that resource against the context in which the current request is generated. If a user requests access to a page, the ACL for that page is evaluated to determine whether the user request should be honored.

There are a few simple rules in determining authorization that handle a large percentage of any conflicts that may arise:

To illustrate these rules and how they are applied to resolve conflict, we return to the example Engineering folder. In the following example, there are three ACE entries in the ACL associated with the Engineering folder:

If Brian is a member of the Marketing group (and even if he wasn't) he is denied access to the Engineering folder. The user-based ACE takes precedence over the group-based ACE so the MARKETING GROUP ACE has no effect. Subsequently, the conflict between BRIAN being granted and denied access is resolved by denying access because DENY always wins.

As mentioned earlier, a Principal can be a user, group, or role. Information about a Principal comes from a directory service. My webMethods Server has an embedded system directory service, described in Managing Directory Services, as well as the ability to tie to external directory servers. Examples of these external directory servers are Active Directory, LDAP servers, ADAM, and an RDBMS. In addition, group and role information for My webMethods Server authorization decisions is determined when a user logs into the server. If a user's group membership changes during an active session, the change is not reflected in the server until the user logs out and logs back in. For more information about users, groups, roles, and directory services, see Managing Users and Groups.

My webMethods Server provides a feature called Security Realms to augment its security model. Security Realms are collections of server resources that share the same ACL. The use of Security Realms makes it possible to easily manage permissions on large numbers of server resources. By adding the resources directly to a Security Realm, a system administrator can add Principal information to that realm to control access.

Security Realms become very useful if you have a large number of server resources and only a few access levels. For example, you may have a large customer-facing server that has a large number of portlets, pages and areas of taxonomy. However, this server may only have three levels of access that need to managed: Gold, Silver and Bronze. With each level represented by a Security Realm with the appropriate pages, portlets and taxonomy elements in them, a system administrator needs only to add a new customer to the appropriate Security Realm, granting the customer the correct level of access. Likewise, changing a customer from one level to another is a simple one-step operation.

Used in the appropriate deployments, Security Realms add value, not only by minimizing the administrative burden, but by greatly reducing the number of underlying records required to support the security model. For example, assume a server has 500,000 server resources and you are managing permissions for 50 users, all of whom have the same access:

It should be noted that if a server resource is added to a Security Realm, the Security Realm access control has precedence over an individual ACL and authentication scheme for that resource.

For information on managing Security Realms, see Using Security Realms.

A server verb is an operation such as publishing, deleting, updating, subscribing, and setting permissions, which is available through the My webMethods Server API. As noted earlier, server verbs are server resources that can also participate in the security model of the server. In this way, one can control granular access to server capabilities programmatically as well as through the Administrative Dashboard. It should be noted that server verbs typically have two levels of security checks, performed in this order:

A system administrator can control access to server verbs using the Security Realms Administrative page. My webMethods Server ships with default Security Realms to help administrators manage access to different server capabilities. For information about the default Security Realms, see Using Security Realms.