Policies

The Policy is the main building block of PolicyServer’s authorization model. It is identified by a name, and that name must be unique across its siblings (see discussions of hierarchy below). It defines the context for authorization rules, and is often used to model an application’s specific authorization requirements.

Policy Model

A single policy has the following components:

• Policy Name - by which it is referred in policy evaluation

• Application Roles - used to group and assign users during evaluation

• Permissions - granular list of named permissions to be assigned through association to application roles

Users can be assigned to an application role via one of these mechanisms:

• User ID Assignment - assign users to an application role by their unique user id (or, subject id)

• Identity Role Assignment - assign users to an application role by mapping their identity role (from authentication) to an application role

• Claims Evaluation Assignment - assign users to a role by executing an expression that takes incoming claims from authentication in an expression

Policy Hierarchy

PolicyServer supports a rich policy hierarchy model. Each policy can have any number of child policies allowing you to model complex application layers, or various types of resource organization.

Each policy in the hierarchy has its own set of application roles, permissions, and assignments. This allows for scenarios whereby:

• Permissions can be created for the appropriate level in the policy hierarchy, as appropriate to the logical relationship to your application features or solution authorization modeling

• Likewise, application roles can be defined at the appropriate level in the policy hierarchy

• Roles and permissions are inherited by their child policies

• Assignment of permissions to roles can be created at any level in the hierarchy

• Assignment of users to roles via role assignments can be created at any level in the hierarchy