Skip to main content

Introduction

Summary​

Astran Continuity Cloud provides a cohesive framework for managing authentication and authorization. In the following sections, you'll learn how these components interact to provide seamless security and how to manage them effectively. This document provides an overview of the access control concepts in our platform. It explains the core components like Partitions, Accounts, Identity Providers (IdPs), Users, Groups, Roles, Policies, and API Keys, which are essential for managing authentication and authorization. Inspired by AWS IAM, our platform leverages these concepts to ensure fine-grained, secure control over user permissions and resource access.

Conceptual Diagram​

The diagram above illustrates how these core components interact within the platform:

  1. Partitions serve as the overarching containers for all resources associated with a customer.
  2. Within each Partition, Accounts manage specific resources, like kits and storage, alongside Roles and Policies that govern access.
  3. Identity Providers (IdPs) manage Users and Groups, handling the authentication flow and associating users with roles.
  4. Roles dictate who and how identities (e.g. Users and API Keys) will be authorized to connect, while Policies provide the permissions for those roles, enabling fine-tuned access control.
  5. Groups aggregate users, simplifying role assignment and management.
  6. API Keys are used for programmatic access, allowing machine-based systems to interact with the platform directly, while Users represent individuals interacting with the solution.

Built-in Resources​

Before diving into the key concepts, it's important to understand that Astran Continuity Cloud distinguishes between built-in resources and customer-defined resources:

  • Built-in Resources: These are pre-configured, standardized components provided by Astran Continuity Cloud. They include default roles, policies, and groups that simplify initial setup and ensure consistent security practices across all customer accounts. Built-in resources cannot be modified but can be utilized and assigned to users, groups, and applications.
  • Customer-Defined Resources: Customers can create and manage their own roles, policies, and configurations to tailor access controls to their specific needs. These resources offer flexibility for organizations to define custom permissions, roles, and integration setups.

Key Concepts​

Partition​

A Partition is a boundary within the platform, ensuring that customer resources are isolated from one another. Each customer gets their unique partition, which can be logical or physical, depending on deployment settings. Partitions contain all resources, accounts, and configurations specific to a customer, providing secure separation.

Account​

An Account exists within a partition and manages specific entities, such as continuity kits, S3-compatible buckets, roles, and policies. While each partition can host multiple accounts, customers are typically assigned a default account that consolidates their core resources.

Identity Provider (IdP)​

Identity Providers (IdPs) handle user authentication and authorization. They determine who can log in and what permissions they have. Each customer is assigned two main IdPs:

  • Root Identity Provider: Provided to managing root users with full administrative privileges.
  • User Identity Provider: Dedicated to managing regular users in the customer's partition, where Users and Groups are configured.

Users​

Users are individuals who authenticate into the platform. They are assigned to Roles that define their permissions. Users can be grouped into Groups, simplifying management and ensuring consistent access control across multiple individuals.

  • Root Users: These users have complete administrative control over all resources within their account, similar to AWS’s root users.

Programmatic Access (API Keys)​

API Keys provide long-term credentials for automated systems and services, bypassing the need for user-based authentication. Unlike users, API Keys are directly linked to Roles within an account, inheriting their permissions.

  • Independent of IdPs: API Keys authenticate without relying on IdPs. They sign programmatic requests to the platform’s CLI, SDKs, or APIs, ideal for automated workflows.
  • Key Management: When an API Key is created, an access key ID and secret access key are generated. Ensure to store the secret securely, as it will not be retrievable once created.

Policies​

Policies define permissions for accessing resources. Inspired by AWS IAM policies, they allow for precise control over what actions can be performed on which resources. Policies are attached to Roles, and there are two types:

  • Account-Specific Policies: Created within an account and can be customized to specific needs.
  • Built-in Policies: Predefined, read-only policies available across all partitions. These can only be attached or detached from account-specific roles.

Roles​

Roles define the identities on which policies will be applied for accessing resources. Assigning roles to Users, Groups, or API Keys grants them specific capabilities within the platform. There are two types of roles:

  • Account-Specific Roles: Created and managed within a specific account, tailored to the customer’s unique needs.
  • Built-in Roles: Predefined roles available across all partitions, such as administrative or standard-user roles, which cannot be modified but can be reused.

The users identities bound to a group are determined by a trust policy, which defines the conditions under which an authenticated identity (like a user or application) can assume the role. Trust policies are essential for associating a role with an IdP. When a role is configured with a trust policy that allows identities (e.g. users belonging to a given group) from an IdP, users with the right attributes authenticated via that IdP can assume the role.

Groups​

Groups facilitate the management of user permissions. Users within a group inherit the group’s assigned Roles, streamlining access control. This setup is ideal for managing permissions across multiple users with similar access needs.

S3-Compatible Resources​

The platform also supports S3-compatible resources, managing versions, objects, and buckets for storage. Roles and Policies can be configured to define who can access or modify these resources, ensuring secure data management.

How It All Comes Together​

The strength of Astran Continuity Cloud’s access control lies in its flexible integration of these components:

  • Partitions ensure security and separation of customer data (kits, buckets, objects, etc...) and metadata via multiples Accounts.
  • IdPs and Groups simplify the management of Users identities, and enforce security rules for user authentication like MFA (multi-factor authentication) and password policies.
  • Roles and Policies provide fine-tuned permissions, RBAC (Role-based access control) can be used to facilitate administration of security in large organizations with hundreds of users and thousands of permissions.
  • Trust Policies ensure that roles are only assumed by authorized identities, adding an extra layer of security, while API Keys are directly bound to a role, extending the concept of identities to programmatic access and allow seamless automation.

These elements collectively create a robust access control system that is easy to manage, yet secure enough to handle complex configurations.

Next Steps​

Now that you have an understanding of the core concepts, explore the following sections for in-depth details on each resource: