Package wt.access

The access control service is responsible for defining and enforcing access to business and system objects.

See:
Description

Interface Summary

AccessControlled	Interface that all classes representing objects subject to access control must implement.
AccessControlManager	The AccessControlManager interface contains the signature of the methods supported by managers of the access control package.
IdentityAccessControlled	IdentityAccessControlled marks classes that require the Modify Identity permission to modify one or more of the identity attributes for instances of the class.

Class Summary

AccessControlHelper	Helper class that provides easy access to the implementation of methods defined by the AccessControlManager interface.
AccessControlServerHelper	Helper class that provides server invokable access control methods.
AccessPermission	AccessPermission represents the access control permissions that may be granted or denied.
AdHocAccessKey	AdHocAccessKey is a specialization of EnumeratedType to provide localizable owner keys for ad hoc access control rule entries.
StandardAccessControlManager	The StandardAccessControlManager provides the standard implementation of a manager for access control.

Exception Summary

AccessControlException	Thrown when the access control service detects an unexpected error.
InvalidAclEntryException	Deprecated.
NotAuthorizedException	Thrown in situations where a user lacks sufficient access rights to carry out an action on a specific object or some other type of authorization error occurs.

Package wt.access Description

The access control service is responsible for defining and enforcing access to business and system objects.

Design Overview

An object is subject to access control if its type implements the AccessControlled interface and implements either the DomainAdministered or the AdHocControlled interface. The AccessControlled interface is simply a marker interface, without any methods. Access control is enforced by access control lists (ACLs), which associate principals to positive or negative sets of access permissions. Permissions are defined by the AccessPermission class. When a user attempts to perform an operation on an object, the ACLs are evaluated according to the model set forth by the java.security.acl.Acl interface, and access is granted or denied.

Two types of ACLs can be associated with an object: a policy ACL, generated from access control policy rules, and an ad hoc ACL, generated from ad hoc access control rules. A single policy ACL applies to all objects within a domain of a specific type and in a specific state, while the ad hoc ACL is specific to a single object. The AccessPolicyRule class defines policy rules and the AdHocControlled interface defines objects with ad hoc rules. Both the AccessPolicyRule class and the AdHocControlled interface implement the AccessControlList interface, which associates a set of entries to an ACL, and both contain an entry set attribute (defined by the AclEntrySet class), which is a cache of the entries. An access control rule entry is defined by the WTAclEntry class.

Access Control Lists

Only a subset of the described access control classes are supported. To determine if a class or one of its methods is part of the Supported API, consult the Javadoc for that class.

Policy ACLs

To be associated to a policy ACL, an object must belong to a domain; that is, its type must implement the DomainAdministered interface (see the wt.admin package). Each domain has its own access control policy that may contain many policy rules and ACLs.

Policy Access Control

Both the policy ACL and the rule contain a selector object that contains information about which domain, type and state they are associated with. They also contain a cached set of entries, each entry representing a specific mapping between a principal (that is, a user, a group, or an organization; see the wt.org package) and a set of permissions. The difference between the policy ACL and the rule is that an ACL is derived from all of the rules that apply to a domain, type and state. Applicable rules include those inherited from ancestor domains and types. See the Windchill Business Administrator's Guide for additional information. Policy ACLs are created on demand and, for performance reasons, stored persistently in the database and in a server cache.

Ad Hoc ACLs

Every object that implements AdHocControlled holds an ACL that is specific to the object, as shown in the figure below.

Ad Hoc Access Control

If an object is both DomainAdministered and AdHocControlled, then both the policy and the ad hoc ACLs determine its access, in an additive manner. Ad hoc ACLs associate principals to a positive set of access permissions, granting additional permissions beyond those defined by policies. In the same way as the policy ACL, the ad hoc ACL also contains a cached set of entries.

Although ACLs can map only principals to permissions, an ad hoc ACL specification (represented by the AdHocAclSpec class) may also map roles to permissions. Ad hoc access control rules can be generated from the ad hoc specification by resolving the roles into principals. Depending on the role to principal mapping used to resolve the roles, the same specification may generate many different ad hoc ACLs.

External Interface

The functionality of this service is represented by the AccessControlManager (accessible through the AccessControlHelper), and the AccessControlManagerSvr (accessible through the AccessControlServerHelper).

StandardAccessControlManager defines the access control enforcement, access control policy, and ad hoc access functionality. For enforcement, the most important method is checkAccess, which takes a permission and an object or a collection of objects as parameters and throws a NotAuthorizedException if access is not granted to the current principal.

Access Control Manager

Business Rules

The rule for access control enforcement returns true (permission granted) if the object is not access controlled, or if it is not ad hoc controlled and doesn't belong to a domain. If the object belongs to a domain, the policy ACL is generated (or retrieved if it already exists), and the ACL is evaluated. In case the object does not belong to a domain or access is not granted by the policy ACL, the object is checked to see if it is ad hoc controlled. If it is and has an ad hoc ACL, the ACL is evaluated and access is granted accordingly. Otherwise, access is denied.

When applying access control enforcement to a DomainAdministered object, the policy ACLs used are those associated with the domain to which the object belongs and those associated with all ancestor domains. This allows objects to have very different access control behavior even if they are of the same type.

Event Processing

The access control manager emits the AccessControlEvent.NOT_AUTHORIZED event if the checkAccess method is called and access is not granted to the current principal.

The access control manager listens for the following events:

• AdministrativeDomainManagerEvent.POST_CHANGE_DOMAIN – When the domain hierarchy changes, the manager reevaluates policy ACLs affected by the changes.

• PersistenceManagerEvent.INSERT – When an AdHocControlled object is created, the manager persists any ad hoc access control entries associated with the object.

• PersistenceManagerEvent.POST_DELETE – When a domain is deleted, the manager deletes the associated policy ACLs.