Reference: Cipherscale Identity and Access Management – Cipherscale Support Center

Abstract

Secure your Cipherscale space with robust Identity and Access Management. Covers user device limits, SAML/OIDC authentication, role inheritance, and context-aware admission rules.

This section covers the core concepts of identity and access management (IAM) within Cipherscale. Understanding how users, groups, roles, and authentication interact is critical for establishing a secure Zero Trust environment, as application access is fundamentally governed by the identity of the user, their devices, and their group memberships, and the context in which the access request is made.

1. Users

A Cipherscale User is any person authorized to use your Cipherscale space and is uniquely identified by their email address.

Device Limits:Users can register up to a maximum of five devices (such as laptops or smartphones) to access the network. Administrators can adjust this limit on a per-user basis or apply a blanket limit to a group.
User Lifecycle & Status: Users are typically invited via email. A user's account status can be monitored as Online (currently using Cipherscale), Offline, Invited (invitation pending), Expired (invitation not accepted within 7 days), or Deactivated (manually disabled by an admin).

2. Groups

A Cipherscale Group represents a set of users who share common access and policy enforcement needs. Grouping users simplifies and organizes the configuration of access policies.

Group Membership: Every Cipherscale user must belong to at least one group, but they can belong to multiple groups simultaneously.
Identity Provider (IdP) Integration: Groups can be mapped to external Identity Providers using SAML. One Cipherscale group can match multiple IdP groups, and via attribute mapping, the same IdP group can map to different Cipherscale groups. You can also enable automatic user group synchronization every time a user signs in.
Conflict Resolution for Multiple Groups: When a user belongs to multiple groups:
- Device Limits: The user is granted the maximum device limit configured among their assigned groups.
- Access Policies: When requesting access to a resource, the system evaluates the prioritized list of access policies. The first access policy that matches any of the user's groups will be the one enforced.

3. Roles and Privileges

Roles determine the administrative and access capabilities a user has within the Cipherscale environment.

Role Types:
- Owner: The creator of the Cipherscale space. They can access resources, configure the solution, and manage billing. This role cannot be inherited from groups. It is a protected role and cannot be overridden when migrating users between groups.
- Admin: Can access resources and fully configure the solution via the administration portal.
- User: Can only use the Cipherscale application to access allowed resources.
Role Inheritance: A Cipherscale Group can only be assigned one specific role. By default, a user inherits their role from their assigned group.
Overlapping Privileges: If a user belongs to multiple groups with different roles, they will inherit the role with the most privileges. For instance, a user in a "User" group and an "Admin" group will operate as an Admin.
Explicit Assignment: Administrators can manually override group inheritance and explicitly assign a different role directly to a specific user.

4. Authentication

Cipherscale supports flexible and secure authentication mechanisms to verify identities before granting access.

Supported Methods: Cipherscale offers native OIDC support for direct integration with Google and Microsoft, as well as Federated SSO for any SAML 2.0 compliant Identity Provider.
Simultaneous Authentication:Multiple authentication methods can be active simultaneously. If multiple are enabled, users can select any available method to sign in.
SAML Customization & Hardening:
- Admins can configure detailed SAML mappings for attributes like Group, Email, Firstname, and Lastname.
- Restricting Authentication Types: Through SAML configuration, administrators can dictate exactly how a user is allowed to authenticate by sending specific AuthnContexts to the IdP. Supported contexts include PasswordProtectedTransport, X509, Passwordless, Kerberos, and TLSClient. This ensures that high-security environments can force passwordless or certificate-based logins.

5. Admission Control

Admission Control works hand-in-hand with access policies to evaluate contextual factors before granting access. In Cipherscale, every Access Policy must be linked to an Admission Rule, and the policy is only enforced if the conditions of the admission rule are met.

Context-Aware Checks: Admission rules qualify a user for access based on their location (e.g., allowed or blocked IP addresses and countries), time constraints (specific times of day or days of the week), and device posture.
How it interacts with Policies: Admission rules do not determine whether access is inherently allowed or denied; instead, they act as a prerequisite condition. The associated Access Policy makes the final allow or deny decision, but only after the Admission Rule criteria are successfully met.

6. Device Identity in Access Policies

Application access in Cipherscale is governed by policies that evaluate not just the user or group, but also the identity of the specific device. You can leverage device identity to restrict or grant access in two primary ways:

Method A: Using Device Posture Admission Rules You can create an Admission Rule that checks a device's specific identity and security posture before granting access. This includes verifying the operating system type (e.g., macOS, Windows, iOS, Android), OS version, the presence of disk encryption, digital certificates, antivirus software, or specific running application processes.

Example: An administrator creates an Admission Rule called "Windows only" that requires a device to be running the Windows OS. An Access Policy is then created to allow a user, Bob, to access salesforce.com, and it is linked to this "Windows only" rule. When Bob attempts to log in, Cipherscale will first check his device posture. He will only be granted access if he is using his Windows device.

Method B: Assigning a Specific Device as a "Source" in an Access Policy Just like Users and Groups, a specific registered Device can be directly assigned as the "Source" value in an Access Policy. This allows administrators to grant or revoke access for a single, specific piece of hardware.

Example: Bob is a user in the "Contractor" group and has two registered devices: an Android phone and a macOS laptop. An existing access policy allows the "Contractor" group to access a private application called timecard. However, the organization wants to ensure Bob can only access the timecard app from his macOS laptop, and not from his Android phone. An admin can create a new Access Policy where the Source is set to Bob's specific Android device, the Action is set to "Deny", and the destination is the timecard app. As long as this device-specific "Deny" policy is placed at a higher priority than the group-wide "Allow" policy, Bob will be successfully blocked from accessing the resource on his phone, while maintaining access on his laptop.