Simple Permission Model Definition Examples

This is for:

Developer System Administrator

Each secured item must have a permission model which you can define or modify using the permissions property when you add or update an item in a secured Push source (see Add or Update a Single Item in a Push Source and Manage batches of items in a Push source). The index uses the permission model of an item, along with the currently available information in the security identity cache, to evaluate the effective permissions of that item (that is, who can or can’t see the item in query results).

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.

The Push API supports two distinct types of permission models: a simplified one (an array of permission sets), and a complete one (an array of permission levels).

The examples in this article assume that you use the simplified permission model, as it’s flexible and powerful enough to allow you to replicate most of the secured enterprise systems you could want to index in a Push source.

If you want to replicate a complex enterprise system with many permission levels and permission sets, consider using the complete model instead (see Complex Permission Model Definition Example).

See also Item Models - PermissionSetsModel

Effective Permission Evaluation with Many 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 simplified permission model:

This process becomes more complex when you use the complete permission model to define many permission levels (see Complex Permission Model Definition Examples - Effective Permission Evaluation with Many Permission Levels and Sets).

Allowing Anyone

This is one of the most basic permission models you can provide for an item in a secured Push source.

{
  "permissions": [
    {
      "allowAnonymous": true
    }
  ]
}

In this example, the permission model contains a single permission set that makes the item essentially public. Any user, authenticated or not, can see this item in query results.

When the allowAnonymous property is true in a permission set, including security identities in the allowedPermissions array is redundant, and can therefore be omitted.

Allowing Only Specific Users

Suppose that the SampleTeam2 group only contains the following members:

  • User cbrown@example.com

  • User dmoore@example.com

{
  "permissions": [
    {
      "allowAnonymous": false,
      "allowedPermissions": [
        {
          "identity": "asmith@example.com",
          "identityType": "User"
        },
        {
          "identity": "SampleTeam2",
          "identityType": "Group"
        }
      ]
    }
  ]
}

In this example, the permission model contains a single permission set that only allows authenticated users asmith@example.com, cbrown@example.com, and dmoore@example.com to see the item in query results.

Allowing Only Specific Users, Except Specific Users

Suppose that:

  • The SampleGroup virtual group only contains the SampleTeam1 and SampleTeam2 groups as members.

  • 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.

{
  "permissions": [
    {
      "allowAnonymous": false,
      "allowedPermissions": [
        {
          "identity": "SampleGroup",
          "identityType": "VirtualGroup"
        }
      ],
      "deniedPermissions": [
        {
          "identity": "SampleTeam2",
          "identityType": "Group"
        },
        {
          "identity": "asmith@example.com",
          "identityType": "User"
        }
      ]
    }
  ]
}

In this example, the permission model contains a single permission set that only allows authenticated user bjones@example.com to see the item in query results.

Allowing Anyone Except Specific Users

This is a rather exceptional, corner case permission model.

Suppose that the SampleTeam1 group only contains the following members:

  • User asmith@example.com

  • User bjones@example.com

{
  "permissions": [
    {
      "allowAnonymous": true,
      "deniedPermissions": [
        {
          "identity": "SampleTeam1",
          "identityType": "Group"
        },
        {
          "identity": "cbrown@example.com",
          "identityType": "User"
        }
      ]
    }
  ]
}

In this example, the permission model contains a single permission set that allows any user except authenticated users asmith@example.com, bjones@example.com, and cbrown@example.com to see the item in query results.

Of course, the three excluded users could easily manage to see the item by performing unauthenticated queries.

Combining Many Permission Sets

Suppose that:

  • The SampleGroup virtual group only contains the SampleTeam1 and SampleTeam2 groups as members.

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

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

  • The MysteryUserX alias resolves to user emitchcell@example.com (see User Alias Definition Examples).

{
  "permissions": [
    {
      "allowAnonymous": true,
      "deniedPermissions": [
        {
          "identity": "asmith@example.com",
          "identityType": "User"
        }
      ]
    },
    {
      "allowAnonymous": false,
      "allowedPermissions": [
        {
          "identity": "SampleTeam1",
          "identityType": "Group"
        },
        {
          "identity": "emitchell@example.com",
          "identityType": "User"
        }
      ]
    },
    {
      "allowAnonymous": false,
      "allowedPermissions" : [
        {
          "identity": "MysteryUserX",
          "identityType": "User"
        }
      ],
      "deniedPermissions": [
        {
          "identity": "SampleGroup",
          "identityType": "VirtualGroup"
        }
      ]
    }
  ]
}

In this example, the permission model contains three permission sets:

  • The first permission set allows anyone except authenticated user asmith@example.com.

  • The second permission set only allows authenticated users asmith@example.com, bjones@example.com, and emitchell@example.com.

  • The third permission set allows authenticated user emitchell@example.com, and denies authenticated users asmith@example.com, bjones@example.com, cbrown@example.com, and dmoore@example.com.

Consequently, when all three permission sets are combined, only authenticated user emitchell@example.com can see the item in query results.