Complete permission model

This is for:

In this article

Effective permission evaluation
Defining many permission levels and sets

The simplified permission model generally lets you properly replicate access rights of the secured enterprise system you want to index. 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 permission model when adding or updating items.

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 lets you explicitly specify another security identity provider if needed.

Effective permission evaluation

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 security identity 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: asmith@example.com performs a query

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: bjones@example.com performs a query

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: cbrown@example.com and dmoore@example.com perform a query

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: emitchell@example.com performs a query

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: An unauthenticated user performs a query

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.