---
title: Simplified permission model
slug: '107'
canonical_url: https://docs.coveo.com/en/107/
collection: index-content
source_format: adoc
---
# Simplified permission model
Each secured [item](https://docs.coveo.com/en/210/) must have a [permission model](https://docs.coveo.com/en/225/) which you can define or modify using the `permissions` property when you add or update an item in a secured Push [source](https://docs.coveo.com/en/246/).
The [index](https://docs.coveo.com/en/204/) uses the permission model of an item, along with the currently available information in the [security identity cache](https://docs.coveo.com/en/241/), to evaluate the [effective permissions](https://docs.coveo.com/en/194/) of that item (that is, who can or can't see the item in [query](https://docs.coveo.com/en/231/) results).

This article describes the simplified permission model, flexible and powerful enough to replicate access rights of most secured enterprise systems.

> **Important**
>
> You can't define [security identities](https://docs.coveo.com/en/240/) in item permission models.
> The permission model of an item must rather _refer to_ existing security identities retrieved through a [security identity provider](https://docs.coveo.com/en/242/).
> For more information, see [Security identity definition examples](https://docs.coveo.com/en/42/) and [User alias definition examples](https://docs.coveo.com/en/46/).
> 
> By default, each object in the [`allowedPermissions`](https://docs.coveo.com/en/78#allowedpermissions-array) and [`deniedPermissions`](https://docs.coveo.com/en/78#deniedpermissions-array) arrays 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.

## Effective permission evaluation

Once a [security identity update](https://docs.coveo.com/en/244/) has been performed and all security identities can be resolved to individual [user](https://docs.coveo.com/en/250/) entities, effective permissions are evaluated as follows for each item with a _simplified_ permission model:

![Flowchart showing how permissions are evaluated to display query results | Coveo](https://docs.coveo.com/en/assets/images/index-content/permissions-evaluation-flowchart.png)

> **Note**
>
> This process becomes more complex when you use the complete permission model to define many permission levels.
> For more information, see [Effective permission evaluation with the complete permission model](https://docs.coveo.com/en/25#effective-permission-evaluation).

## Allowing Anyone

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

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

In this example, the permission model contains a single permission set that makes the item essentially public.
Any user, [authenticated](https://docs.coveo.com/en/2120/) or not, can see this item in query results.

> **Note**
>
> 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` [security identity group](https://docs.coveo.com/en/202/) only contains the following members:

* User `cbrown@example.com`
* User `dmoore@example.com`

```json
{
  "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](https://docs.coveo.com/en/252/) 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.

```json
{
  "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`

```json
{
  "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](https://docs.coveo.com/en/176/) resolves to user `emitchell@example.com`.
For more information, see [User alias definition examples](https://docs.coveo.com/en/46/).

```json
{
  "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.