GridGain Developers Hub
GitHub logo GridGain iso GridGain.com
GridGain Software Documentation

Authorization and Permissions

Authorization occurs after successful authentication of subjects (remote nodes or clients). Once a subject is authenticated, it is assigned a set of preconfigured permissions. Permissions are associated with the users in the authenticator configuration.

Permission String Format

Permissions are configured as a single string in the following almost JSON-like format (spaces and newline characters are ignored):

{
    "defaultAllow":"false",
    {
        "cache":"mycache",
        "permissions":["CACHE_READ", "CACHE_PUT", "CACHE_REMOVE"]
    },
    {
        "cache":"*",
        "permissions":["CACHE_READ"]
    },
    {
        "task":"org.mytasks.*",
        "permissions":["TASK_EXECUTE"]
    },
    {
        "service":"*",
        "permissions":["SERVICE_INVOKE"]
    },
    {
        "system":["ADMIN_VIEW", "CACHE_CREATE", "JOIN_AS_SERVER"]
    }
}

The example given above defines the following permissions:

  • all operations that are not listed explicitly are disallowed

  • read, put and remove operations are allowed for the cache "mycache"

  • read operations are allowed for any cache

  • the tasks that are in the package "org.mytasks.*" can be executed

  • any service can be invoked

  • the user can create caches, join the cluster as a server node

  • Web Console can view cluster statistics

The defaultAllow property indicates whether the missing permissions (those that are not listed explicitly) default to true or false. If defaultAllow is false, the listed operations are allowed and all other operations are disallowed. If defaultAllow is true, the listed operations are not allowed and all other operations are.

Supported Permissions

GridGain supports the following permissions:

Cache permissions:

  • CACHE_READ - cache read operations

  • CACHE_PUT - cache put operations

  • CACHE_REMOVE - cache remove operations

Task permissions:

  • TASK_EXECUTE - task execution

  • TASK_CANCEL - task cancellation

Service permissions:

  • SERVICE_DEPLOY - service deployment

  • SERVICE_INVOKE - service invocation

  • SERVICE_CANCEL - service cancellation

System permissions:

  • JOIN_AS_SERVER - node joining the cluster as server

  • EVENTS_ENABLE - enabling events in runtime

  • EVENTS_DISABLE - disabling events in runtime

  • ADMIN_OPS - operations executed from Web Console

  • ADMIN_VIEW - viewing cluster statistics (metrics, graphs, cache sizes, etc.) in Web Console

  • ADMIN_QUERY - executing SQL queries from Web Console

  • ADMIN_CACHE - cache operations executed from Web Console (data loading, manual rebalancing, etc.)

  • CACHE_CREATE - creating new caches (including ones specified in the node configuration)

  • CACHE_DESTROY - destroying existing caches

Specifying Scope of Permissions

Note that you can use wildcard patterns to indicate the scope of the permissions. For example, the following string allows read operations for all caches:

{
    "cache":"*",
    "permissions":["CACHE_READ"]
}

This string allows read operations for the caches whose name starts with "person".

{
    "cache":"person*",
    "permissions":["CACHE_READ"]
}

The following table explains how the scope is defined:

Permission Scope Definition

Cache permissions

Cache name.

Task permissions

Task’s full class name (including the package).

Service permissions

Service’s full class name (including the package).

System permissions

Do not have a scope.