# Resource-level permissions in AWS User Notifications
Resource-level permissions

*Resource-level permissions* define the AWS resources that you allow assigned entities (users, groups, and roles) to perform actions on. You specifiy the Amazon Resource Name (ARN) of one or more resources as part of an IAM policy. You can then attach this policy to IAM entities. When the action doesn't act on a named resource, or when you grant permission to perform the action on all resources, the value of the resource in the policy is a wildcard (\$1). 

**Note**  
AWS User Notifications doesn't support *resource-based policies*, which are directly attached to AWS resources. For more information about the differences between policies and permissions, see [Identity-based policies and resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) in the *IAM User Guide*. 

 For more information about defining resource-level permissions, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*. 

## Supported resource-level permissions for User Notifications API actions


 This table describes the User Notifications API actions that currently support resource-level permissions, as well as the supported resources for each action, including their ARNs and ARN format. 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/notifications/latest/userguide/resource-level-permissions.html)

## Example 1: Full access


This policy allows a user to call all available APIs.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "notifications:*",
        "notifications-contacts:*"
      ],
      "Resource": "*"
    }
  ]
}
```

------

## Example 2: ReadOnly access


This policy allows a user to use get and list API actions.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "notifications:Get*",
        "notifications:List*",
        "notifications-contacts:Get*",
        "notifications-contacts:List*"
        
      ],
      "Resource": "*"
    }
  ]
}
```

------

## Example 3: Deny a user the ability to update a notification configuration


This policy denies a user the ability to update a notification configuration.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "notifications:UpdateNotificationConfiguration"
      ],
      "Resource": "arn:aws:notifications::123456789012:configuration/a01gkn2k10c7spt0a8x8nj55555"
    }
  ]
}
```

------

## Example 4: Allow users to create notification configurations and associate emails to them


This policy allows users to create notification configurations and associate emails to those configurations.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
       "iam:CreateServiceLinkedRole",
       "notifications:RegisterNotificationHub",
       "notifications:CreateNotificationConfiguration",
       "notifications:CreateEventRule",
       "notifications:AssociateChannel",
       "notifications-contacts:CreateEmailContact",
       "notifications-contacts:SendActivationCode",
       "notifications-contacts:ActivateEmailContact"
      ],
      "Resource": "*"
    }
  ]
}
```

------

## Example 5: Allow users full create, read, update, and delete (CRUD) access.


This policy allows users full CRUD access.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
      "iam:CreateServiceLinkedRole",
      "notifications:*",
      "notifications-contacts:*"
      ],
      "Resource": "*"
    }
  ]
}
```

------