Complex Permission Model Definition Example

This is for:

Developer System Administrator

Typically, the simplified type of permission model offered by the Push API should allow you to adequately replicate the secured enterprise system you want to index in a secured Push source (see Simple Permission Model Definition Examples). However, some complex secured enterprise systems may require you to define a hierarchy of permission levels where the permissions derived from a higher permission level supersede those derived from subsequent lower permission levels. In such cases, you should use the complete type of permission model when adding or updating items in your secured Push source.

You can’t define security identities in item permission models.

The permission model of an item must rather refer to existing security identities retrieved through a security identity provider (see Security Identity Definition Examples and User Alias Definition Examples).

By default, each PermissionIdentityModel is assumed to reference an existing security identity retrieved through the first security identity provider associated with the target Push source. The securityProvider property allows you to explicitly specify another security identity provider if needed.

See also Item Models - PermissionLevelsModel.

Evaluating Effective Permissions with Many Permission Levels and Permission Sets

Once a security identity update has been performed and all security identities can be resolved to individual user entities, effective permissions are evaluated as follows for each item with a complete permission model:

Defining Many Permission Levels and Sets

Suppose that:

  • The SampleTeam1 group only contains users asmith@example.com and bjones@example.com as members.

  • The SampleTeam2 group only contains users cbrown@example.com and dmoore@example.com as members.

  • The MysteryUserX alias resolves to user emitchell@example.com.

{
  "permissions": [
    {
      "name": "Permission Level 1",
      "permissionSets": [
        {
          "allowAnonymous": true
        },
        {
          "allowAnonymous": false,
          "allowedPermissions": [
            {
              "identity": "SampleTeam1",
              "identityType": "Group"
            }
          ],
          "deniedPermissions": [
            {
              "identity": "SampleTeam2",
              "identityType": "Group"
            }
          ]
        },
        {
          "allowAnonymous": false,
          "allowedPermissions": [
            {
              "identity": "asmith@example.com",
              "identityType": "User"
            },
            {
              "identity": "cbrown@example.com",
              "identityType": "User"
            }
          ],
          "deniedPermissions": [
            {
              "identity": "bjones@example.com",
              "identityType": "User"
            }
          ]
        }
      ]
    },
    {
      "name": "Permission Level 2",
      "permissionSets": [
        {
          "allowAnonymous": false,
          "allowedPermissions": [
            {
              "identity": "bjones@example.com",
              "identityType": "User"
            },
            {
              "identity": "emitchell@example.com",
              "identityType": "User"
            }
          ],
          "deniedPermissions": [
            {
              "identity": "asmith@example.com",
              "identityType": "User"
            }
          ]
        },
        {
          "allowAnonymous": false,
          "allowedPermissions": [
            {
              "identity": "MysteryUserX",
              "identityType": "User"
            }
          ]
        }
      ]
    }
  ]
}

Case 1: User asmith@example.com

User asmith@example.com performs a query whose results would contain the item.

This user isn’t specifically denied in any of the Permission Level 1 permission sets, and is specifically allowed in all of those permission sets.

Therefore, even though Permission Level 2 would deny user asmith@example.com, Permision Level 1 takes precedence, and the user can see the item in query results.

Case 2: User bjones@example.com

User bjones@example.com performs a query whose results would contain the item.

This user is specifically denied in at least one of the Permission Level 1 permission sets.

Therefore, even though Permission Level 2 would allow user bjones@example.com, Permission Level 1 takes precedence, and the user can’t see the item in query results.

Case 3: Users cbrown@example.com and dmoore@example.com

Users cbrown@example.com and dmoore@example.com each perform a query whose results would contain the item.

Those users are both specifically denied in at least one of the Permission Level 1 permission sets.

Therefore, neither of those users can see the item in query results.

Case 4: User emitchell@example.com

User emitchell@example.com performs a query whose results would contain the item.

This user is unknown in Permission Level 1. Consequently, Permission Level 2 is evaluated.

User emitchell@example.com isn’t denied in any of the Permission Level 2 permission sets, and is specifically allowed in all of those permission sets.

Therefore, the user can see the item in query results.

Case 5: Unauthenticated user

An unauthenticated user performs a query whose results would contain the item.

Unauthenticated users are denied in at least one of the Permission Level 1 permision sets.

Therefore, the user can’t see the item in query results.