Get Started

Cloudentity Concepts and Terms

Familiarize yourself with the most commonly used terms and concepts within the Cloudentity ecosystem.

Application (Client and Service)

In Cloudentity, Application is defined as a Client and Service. Client can be understood as the OAuth 2.0 Client. Services are a bit more complicated. Essentially, the whole set of services in a Cloudentity Workspace constitutes the OAuth 2.0 Resource Server. Cloudentity recognizes that such a server can expose a large number of APIs grouped into particular services, and consequently represents this in the Workspace in order to allow for more fine-grained access control.

Authorizer

Authorizers are responsible for access control at API level. They act a localized policy decision point (PDP) integrated with and localized close to a policy enforcement point (PEP) like API Gateways. Authorizers are connected to the Cloudentity platform that acts as a policy administration point (PAP) and policy information point (PIP). The authorizer fetches the policies configured for APIs and services from the Cloudentity Platform. It allows for policy unification across different environments and API gateways in multi-cloud systems. It also allows for externalized authorization. When integrated, API gateways or Service Meshes can externalize the authorization to Cloudentity and its authorizers. When the request reaches the gateway, the gateway can invoke the authorizer, delegating access control to it. Authorizer and its built-in policy engine can evaluate the policy result and based on the outcome, deny or allow access.

For more information, see API Gateway authorization with Cloudentity.

Authorization Server

The authorization server is an engine/system component that is used for minting Access and Identity Tokens (OAuth 2.0 and OIDC compatible) to enable secure data sharing between different web applications. Cloudentity’s administrator portal allows for the configuration of authorization server capabilities, including grant types management, token settings, client registration, and client authentication. Cloudentity allows to create multiple authorization servers per tenant.

Cloudentity Authorization Server serves as a Policy Information Point (PIP) where the information on policies and their definition is stored to be passed to authorizers.

BYOID

Bring Your Own Identity (BYOID) is a philosophy that Cloudentity strongly believes in. Cloudentity allows you to integrate the platform with your existing identity sources using open standards such as OpenID Connect and SAML.

To make it easier for you to integrate solutions, Cloudentity has a vast number of built-in Identity Connectors for major Identity Sources that allow you to quickly connect your Identity Source to the platform. If your Identity Source does not have a dedicated connector in Cloudentity , but shares identity information using either OIDC or SAML standard, you can use a generic OIDC or SAML connector instead. Most of the provided out of the box connectors comply with the OIDC standard, but you can also use the SAML generic connector to integrate your identity source in a SAML-compliant way.

Additionally, if your Identity Source is not following the OIDC or SAML standards, you can build your own custom connection or integrate Cloudentity with an external datastore. It requires more work on your side, but allows you to bring Cloudentity with its advanced authorization and governance capabilities into your system to make sure your applications and APIs are secure.

Extension Scripts

Cloudentity allows you to write JavaScript extension scripts in a convenient embedded environment so that you can modify the Cloudentity authentication context. Once written, you can enable the scripts on individual Identity Sources so that they are executed after user authentication.

Identity Pools

Identity Pool allows for the persistent storage of user data within Cloudentity’s infrastructure, thus providing the alternative to the Bring Your Own Identity (BYOID) approach typically used by Cloudentity SaaS tenants. Having added an Identity Pool to your tenant, you can connect it as an Identity Source to specific workspaces so that the end-users can log in to Cloudentity (or register in the Identity Pool first).

Identity Schema

Identity Schema in Cloudentity is complementary to Identity Pools, allowing for the validation of user data being processed within Identity Pools. All Identity Pools have a schema assigned for user payload and user metadata - standard properties in most requests.

Technically, Identity Schema is represented witgh a JSON schema which determines how the payload and metadata objects, conveying user data, must be structured in the Identity APIs. We have two types of Identity Schemas:

  • Payload schema - used to define and validate the payload structure of user-related requests (for example, the presence of user’s first name and last name)

  • Metadata schema - used to define and validate the metadata structure of user-related requests. Metadata is read-only from user’s perspective. Parameters marked as hidden: true in the schema are hidden from users calling the Self Get User Profile endpoint.

Cloudentity provides system Identity Schemas for payload and metadata - those schemas are assigned to Identity Pools by default and cannot be modified or deleted. A sample payload schema with added e-mail and custom parameters could look as follows:

Object Description
properties An array of objects where each object represents a property to be entered by the user
description Schema description for identification purposes. This description is displayed as a header on the user registration form.
type Schema data type - there should be no need to change this as the schema will always be an object.
required List of mandatory properties for user registration
{
    "properties": {
        "family_name": {
        "description": "user last name",
        "type": "string",
        "minLength": 1
        },
        "given_name": {
        "description": "user first name",
        "type": "string",
        "minLength": 1
        },
        "name": {
        "description": "user full name",
        "type": "string",
        "minLength": 1
        },
        "e-mail": {
        "description": "user e-mail",
        "type": "string",
        "minLength": 1,
        },
        "custom": {
        "description": "custom attribute",
        "type": "boolean",
        "minLength": 1
        }
    },
    "description": "sample user data schema",
    "type": "object",
    "required": [
        "family_name",
        "given_name",
        "name",
        "e-mail",
        "custom"
    ]
}

When the above Identity Schema is assigned as a payload schema to the Identity Pool, the e-mail and custom parameters must be passed in the payload object for the request to succeed. On the UI side, the users and administrators are also prompted to fill in the required data to satisfy the schema:

You can check how to configure and assign schemas in Configuring Identity Pools.

Policy

Cloudentity Policies provide the multilevel authorization as the response to modern access control requirements. Cloudentity supports the Rego policy standard, but it also provides a native policy editor.

Sample Policy

Policies are evaluated on several levels, starting from the entire worspace, down to a single API:

  1. Workspace level

    All requests that happen in the context of the workspace have this policy evaluated first. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, Cloudentity responds with the 403 error to a token request.

  2. Application level

    If a policy is assigned to a client application that requests a token, the policy is evaluated as a part of the OAuth authorization and authentication process. To learn more this process, see OAuth documentation. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, Cloudentity responds with the 403 error to a token request.

  3. OAuth scope / service level

    If an application requests a specific scope with a policy assigned to it, the policy is evaluated. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, Cloudentity still returns a token to the application, but the token does not include the scopes for which the policy evaluation ends with a failure.

  4. API layer level

    API layer is evaluated if you use the authorizers as an API enforcement layer. API policies evaluate the context of the request and context of the client or the user that is included in the access token. If the policy passes, the authorizer allows this API request. If it fails, the API request is blocked. If you are using Istio Authorizer, you can add a layer of policy orchestration using the native Istio policy and describe the conditions under which the Cloudentity authorization needs to be evaluated.

User portal

The Cloudentity user portal offers all the features that end users need to manage authorizations and consents that they grant to their applications.

  • If you do have authorized applications, the Cloudentity user portal shows them listed as Third-party applications with account access.

  • If you have not authorized any applications to access your account, the Cloudentity user portal displays message You haven’t granted consents to any applications yet.

Developer portal

The Cloudentity developer portal offers all the features that a developer needs to manage applications easily and securely with Cloudentity.

  • If you already have applications in Cloudentity, the Cloudentity developer portal opens with the preview of your applications and enables you to configure their settings and access details (1). You can also add more applications with CREATE APPLICATION (2).

  • If you have no applications created in Cloudentity so far, the Cloudentity developer portal opens with CREATE APPLICATION, which invites you to build your new applications.

Workspace

Workspace is the main administration interface of Cloudentity, that consists of an Authorization Server, integrated sources of identities, connected Applications and Authorizers (being an access control enforcement point and integration point for API gateways and Service Meshes). You can create multiple Workspaces in a tenant in order to support different use-cases (for example, meeting the Open Banking requirements or Partners B2B integration).