Deny service access

Service access denials enable you to block tenants from accessing one or multiple services or specific resolvers on a service. Denying access is applicable only at tenant level, and only for a specific app. It does not make sense to deny access at app level (nor is this possible), since this would effectively block all tenants using that app.

In the event that some scope is first granted and then a subset of that scope is denied, the denied scope will invalidate only the subset that it covers. For example, let’s assume that a tenant has a service access key whose scope provides access to all services. If you subsequently deny the tenant the scope email-api:mutation:sendMessage, they will no longer be able to send email messages, but they will still be able to access all other services and resolvers.

You can add service access denials either through the graphical user interface (Web UI) or from GraphQL. Also, service access denials can be revoked (deleted) at any time, which effectively means that the tenant’s access to the resource is restored.

Add a service access denial from the Web UI

To add a service access denial from the Web UI:

1. Sign in to the SBS Console and click the WebUI tab if it’s not already selected.

2. In the left-hand side navigation menu, click Tenants.

3. Click the tenant for which service access must be denied.

4. Click the Add button in the top-right corner of the service access denials table. A dialog box appears.

5. Under Application, select the application where the denial should take effect.

6. Under Scope, enter the scope of the denial. This is a mandatory field. For example, to deny the tenant the ability to send email, enter email-api:mutation:sendMessage. For details, see Scope editor.

7. Under Reason, enter the message that should be returned to the API callers when they attempt to access a denied resource (be it a service, query, or mutation). For example, “Access to this resource is restricted to paying customers.”.

   

8. Click Deny Service Access.

Any service access denials you create are shown in the service denials table, for example:

To revoke a service access denial, click its Remove button in the table. This will restore tenant’s access to the resource, with immediate effect.

Add a service access denial from GraphQL

To add a service access denial from GraphQL:

1. Sign in to the SBS Console and click the GraphQL tab. Alternatively, access the Account API programmatically from your own GraphQL development environment.

2. Run the following mutation:

   Copy

   mutation denyServiceAccess($input:DenyServiceAccessInput!) {
     denyServiceAccess(input:$input) {
       id
       tenantId
       appId
       scope
       reason
       createdAt
     }
   }
   

3. In the variables, make sure to replace the examples values below with the ones you actually require:

   • tenantId - the ID of the tenant who must be denied access.
   • appId - the ID of the app where access must be denied.
   • scope - the extent of the denied scope. For example, if you set the scope to email-api:mutation:sendMessage, the tenant tenantId will no longer be able to send email messages from the app identified by appId. For more information about the syntax rules, see Restrict access to services.
   • reason - the message that should be returned to the API callers when they attempt to access a denied resource (be it a service, query, or mutation). For example, “Access to this service is restricted to paying customers.”.
   Copy

   {
       "input": {
           "tenantId": "YOUR_TENANT_ID",
           "appId": "YOUR_APP_ID",
           "scope": "email-api:mutation:sendMessage",
           "reason": "Access to this resource is restricted to paying customers."
       }
   }
   

The denyServiceAccess mutation returns, among other fields, a denial ID. You may need this denial ID later, if you ever need to revoke the denial (that is, restore access to the tenant).

To revert any of the previous denials, run the revokeServiceAccessDenial mutation, and provide the following parameters as input:

• tenantId - the ID of the tenant whose access must be restored.
• appId - the ID of the app where access must be restored.
• denialId - the ID of the denial record that must be revoked (deleted).

For example:

mutation revokeServiceAccessDenial($input:RevokeServiceAccessDenialInput!) {
  revokeServiceAccessDenial(input:$input) {
    id
    tenantId
    appId
    scope
    reason
    createdAt
  }
}

{
    "input": {
        "tenantId": "YOUR_TENANT_ID",
        "appId": "YOUR_APP_ID",
        "denialId": "YOUR_DENIAL_ID"
    }
}