Cloudentity Permission Service

Intro

Cloudentity provides comprehensive authorization for Users, Services and Things using a combination of controls including

Access Based Access Controls (ABAC)
Role-Based Access Control (RBAC)
Advanced Risk Based Authorization Capabilities (RADAC)

Additionally, Cloudentity is able to communicate with existing authorization and fraud engines to inform the authorization model with real-time threat information such as compromised IP address, devices or other contextual, custom validation elements.

These authorization models are crafted in the central policy administration platform – the Cloudentity TrUST Engine. The TrUST Engine supports traditional security protocols such as SAML and OAuth but also extends security and authorization by distributing policy decision and enforcement to a range of security fronts such as the MicroPerimeter™ Sidecar or MicroPerimeter™ Gateway.

The Cloudentity Authorization engine allows the modeling of complex decision trees to provide flexible and adaptive authentication and authorization flows. These models can be applied on when the client first authorizes, but can also be applied at any point during the application flow. This allows for non-binary access control to protected resources, meaning high-value resources (e.g. a financial transaction) may require additional authorization than a low value transaction (e.g. accessing corporate content).

The non-binary aspect of the access control is expressed not only in adaptive decision-making capabilities informed by dynamic attributes and states, but also in non-binary decision outcomes that adapt to the situation and context. The TrUST Engine gives far more than a simple yes/no decision; it supplies mitigation steps in order to guide the client on how to overcome initially denied access.

Overview

The Cloudentity Permission Service can be used to model RBAC,ABAC or fine grained entitlement assignment scenarios. This service allows the specification of permissions and grants, either on a per-tenant basis or at the system level. Cloudentity Permission Service is used as a permission definition, grant and storage model; however the permissions evaluation and enforcement might be distributed between the Cloudentity TrUST Engine and application specific logic that can be utilized to provide permission grants for fine grained authorization.

The Cloudentity Permission Service defines following entities.

Permission — definition of a permission. Permission can be defined a:
- system permission - defined at the global level and potentially available to all tenants
- tenant permission - defined at the tenant ( organization/customer) level and only visible for user and delated administrators under that particular organization.
- application permission - defined at the tenant and application level. Permission limited only to specific application.
Permission Grant — object representing the assignment of the specific permission to a principal (user, application, etc.). Cloudentity Distributed Permissions model allows two types of permission grants.
- service permission grant - permission is granted to a principal ( user/organization/application etc…). There is no limitation regarding the objects that this permission applies to; apart of the context already defined as part of the permission itself ( application or tenant specific)
- object permission grant - permission is granted to a principal to act on specific objects (health record, device, other user, etc.). Object permission grants provide the additional dimensions to the model and allow definition of fine grained access control
Role — collection of permissions that can be granted to a principal. Role

Permissions

Permission Service provides coarse and fine-grained authorization capabilities.

It’s functionality revolves around 2 questions:

Is user X allowed to perform action A?

Is user Y allowed to perform action B on device D?

First question is coarse-grained and has 2 parts:

Is user X (Principal) allowed to perform action A (Permission)?

Second question is fine-grained and has 3 parts:

Is user Y (Principal) allowed to perform action B (Permission) on device D (Object)?

Key entities

Permission: description of an action that can be performed by Principal
Principal: abstract entity for whom a Permission can be granted, e.g. User, Application, Device, Group, etc.
Object: abstract entity to which a Permission can be granted for Principal
Service Permission Grant: an evidence that a Principal has a Permission (without restriction to specific object), i.e. a Principal can perform an action described by Permission
Object Permission Grant: an evidence that a Principal has a Permission to an Object, i.e. a Principal can perform an action described by Permission on an Object

The answer to first question is positive only if there is Service Permission Grant stored. Correspondingly, the answer to second question depends on Object Permission Grant.

Roles

Roles provide a way to manage multiple Permissions. Instead of granting several Permissions to Principal and/or Object we can group Permissions in a Role and then grant the Role. Effectively, each Permission from the Role is used to create Service Permission Grant or Object Permission Grant.

Key entities

Role: grouping of Permissions
Role Permission: relation between Role and Permission, defines what Permission Grant will be created when the Role is granted to Principal and/or Object

Service Role Permission	used to create Service Permission Grant when the Role is granted
Static Object Role Permission	used to create Object Permission Grant, Object is defined when adding Permission to Role

Role with Service Role Permission example

Given ADMINISTRATOR Role with following Role Permissions:

Role Permissions of Role ADMINISTRATOR
Type	Permission
Service	CREATE_USER
Service	DELETE_USER

when we grant Role ADMINISTRATOR to Principal user:USER it results in creating Service Permission Grants for CREATE_USER and DELETE_USER Permissions:

Permission Grants
Type	Permission	Principal	Object
Service	CREATE_USER	user:USER	-
Service	DELETE_USER	user:USER	-

Role with Static Object Role Permission example

Given ROOM_X_ADMINISTRATOR Role with following Role Permissions:

Role Permissions of Role ROOM_X_ADMINISTRATOR
Type	Permission	Object
Static Object	MANAGE_LIGHTS	room:X
Static Object	MANAGE_WINDOWS	room:X

Note	We can have different Object for each Role Permission in a Role.

when we grant Role ROOM_X_ADMINISTRATOR to Principal user:USER it results in creating Object Permission Grants for MANAGE_LIGHTS and MANAGE_WINDOWS Permissions and Object room:X:

Permission Grants
Type	Permission	Principal	Object
Object	CREATE_USER	user:USER	room:X
Object	DELETE_USER	user:USER	room:X

Note	We can have different types of Role Permissions in a Role.

Examples

Permissions

Below are several examples of permission definitions for various use-cases and scenarios. Permissions can be defined at the global level (system permission to be granted across various tenants) or locally ( - tenant permission defined at a tenant level, application permission defined at an application or even microservice level).

A permission definition consists of three main components:

key (required) — permission composite key that must include at least the name attribute, plus an optional reference to customerId (for a tenant-specific permission) and/or an applicationId (for cases where the permission applies only to a specific application or microservice).

If the customerId is omitted, the permission is defined as a global one. If the applicationId is omitted, the permission is defined as an application-independent permission.
grantPolicies (optional) — reference to an authorization policy that controls the grant/list/revoke process for that particular permission. Grant policies allow fine-grained control on how the permission can be assigned, revoked, modified, deleted or listed.
metadata (optional) — additional metadata that can be utilized to store integration-specific information.

In summary, the permission definition is as follows:

{
  "key": {
    "name": "string",
    "customerId": "string",
    "applicationId": "string"
  },
  "grantPolicies": {
    "create": {
      "name": "string"
    },
    "delete": {
      "name": "string"
    },
    "list": {
      "name": "string"
    },
    "check": {
      "name": "string"
    }
  },
  "metadata": {

  }
}

The following examples shows the several uses of permission definitions. In these examples, the metadata section of the definition includes information about endpoints and rights.

Note	The content of the metadata attribute is flexible and can be defined to match client-specific requirements. Metadata is not being used by any of the Cloudentity components directly; rather, it is available for application-specific logic.

Permission ⇒ Permission definition to perform any operations on IOT devices at the tenant level:

{
  "key": {
    "name": "DEVICES_ALL",
    "customerId": "acme_smart_lights_id"
  },
  "metadata": {
    "resources": {
      "/devices/lights": {
        "rights": ["GET","POST","PUT","DELETE"]
      }
    }
  }
}

Permission ⇒ Permission definition to read audit logs:

{
  "key": {
    "name": "AUDITLOGS_READ",
    "customerId": "secure_mssp_id"
  },
  "metadata": {
    "resources": {
      "/auditLog": {
        "rights": ["GET"]
      }
    }
  }
}

Permission ⇒ Permission definition to read electric meter endpoints applicable only to the smart meter app:

{
  "key": {
    "name": "METER_READ",
    "customerId": "acme_electric_company",
    "applicationId" ; "smart_meter_app_id"
  },
  "metadata": {
    "resources": {
      "/energystats/meter/{meterid}": {
        "rights": ["GET"]
      }
    }
  }
}

Permission ⇒ Permission definition for read-only access on all resources for a selected application owned by the tenant:

{
  "key": {
    "name": "ALLENDPOINTS_READ",
    "customerId": "advertising",
    "applicationId" : "success_dashboard_app_id"
  },
  "metadata": {
    "resources": {
      "*": {
        "rights": ["GET"]
      }
    }
  }
}

Note	The metadata definition is useful for the implementation of the enforcement logic at the application level. However, it is not required by the Cloudentity system.

Permission Grants

Permission grants allow a permission to be assigned to a principal. A Principal can be an any primary entity in the Cloudentity System (user, organization, application, or device).

Permission grant can limit the scope of the permission to only a particular object by referencing the object in a grant. Adding the object reference allows the regular service permission grant to become an object permission grant. An object can be anything that is recognized by the integrated system and enforcement logic. Examples include:

user — principal has a capability to operate on limited user records
customer — principal has a capability to operate on limited customers (tenants)
records — set of data records
devices — set of devices
logs — set of logs
etc.

A Permission Grant definition includes the following:

a reference to a permission via permissionKey
a reference to a principal (for example, a user) to which the permission is granted
a reference to an object to which this permission is applied ( only for object permission grants)

A permission may optionally be limited to a specific time frame by utilization of the notBefore and expiresAfter claims.

{
  "permissionKey": {
    "name": "string",
    "customerId": "string"
  },
  "principal": "user:user-uuid",
  "object" : "device:device-uuid",
  "grantedBy": {
    "userId": "a4e0e-c69e-45e2-bd3e-a176cc"
  },
  "notBefore": 0,
  "expiresAfter": 0,
  "metadata": {

  }
}

The following examples demonstrate various permission grant usages:

Permission Grant ⇒ System permission grant to denote read medical access for a "user" principal:

{
  "permissionKey": {
    "name": "DEVICES_READ",
    "customerId": "acme-hospital-cid"
  },
  "principal": "user:3a47f-159ec308-430143-2344d",
  "grantedBy": {
    "userId": "a4e0e-c69e-45e2-bd3e-a176cc"
  },
  "notBefore": 0,
  "expiresAfter": 0,
  "metadata": {}
}

Permission Grant ⇒ Object permission grant to denote read access for a "user" principal on an object that is defined as a specific device group. This model is equivalent to a constraint model on the permissions of the user:

{
  "permissionKey": {
    "name": "DEVICES_READ",
    "customerId": "acme-hospital-cid"
  },
  "principal": "user:3a47f-159ec308-430143-2344d",
  "object": "devices_group:insuline_pomps",
  "grantedBy": {
    "userId": "a4e0e-c69e-45e2-bd3e-a176cc"
  },
  "notBefore": 0,
  "expiresAfter": 0,
  "metadata": {}
}

Permission Grant ⇒ Object permission grant to denote read access for a "user" principal on an object for all devices that belong to particular tenant:

{
  "permissionKey": {
    "name": "DEVICE_EP_ACCESS_READ",
     "customerId": "acme-hospital-cid"
  },
  "principal": "user:3a47f-159ec308-430143-2344d",
  "object": "devices_group:*",
  "grantedBy": {
    "userId": "a4e0e-c69e-45e2-bd3e-a176cc"
  },
  "notBefore": 0,
  "expiresAfter": 0,
  "metadata": {}
}

Cloudentity Permission Service

Intro

Overview

Permissions

Roles

Examples

Permissions

Permission Grants

See Also