Authentication & access control

Alpacon implements robust authentication and access control mechanisms to ensure only authorized users can access your infrastructure.

Authentication infrastructure

For Alpacon Cloud, Alpacon uses Auth0 by Okta as our authentication provider, delivering enterprise-grade security and reliability:

Why Auth0?

• Industry leader: Auth0 (acquired by Okta) is a trusted identity platform used by thousands of enterprises
• Certified security: SOC 2 Type II, ISO 27001, and PCI DSS certified
• Compliance ready: Supports GDPR, HIPAA, and other regulatory requirements
• High availability: 99.99% uptime SLA with global infrastructure
• Continuous security: Regular security audits and updates by Okta’s security team
• Advanced threat detection: Built-in protection against credential stuffing, brute force attacks, and anomalous login patterns

Benefits for Alpacon users

By leveraging Auth0, Alpacon provides:

• Proven security: Battle-tested authentication used by Fortune 500 companies
• Transparent trust: Auth0’s security certifications and compliance reports are publicly available
• Rapid security updates: Immediate protection against newly discovered authentication vulnerabilities
• Feature richness: Access to advanced authentication features (MFA, SSO, adaptive authentication)
• Reliability: Geographic redundancy and automated failover ensure authentication is always available

Security note: While Alpacon uses Auth0 for authentication, we maintain full control over authorization and access policies. Auth0 handles “who you are” (authentication), while Alpacon controls “what you can do” (authorization).

Authentication methods

Email & password

For Alpacon Cloud, login is handled by Auth0:

• Email/password login: Authentication with email and password
• Password storage and protection: Passwords are stored and verified by Auth0, not by Alpacon. Auth0 provides brute-force and credential-stuffing protection and breached-password detection.

Multi-factor authentication (MFA)

MFA adds an additional layer of security to user accounts:

Supported MFA methods

Alpacon supports the following MFA methods (a workspace can restrict which ones are allowed):

• Hardware security key: WebAuthn-compatible keys such as YubiKey. Phishing-resistant and the strongest option.
• Biometric authentication (FaceID, Fingerprint): Your device’s built-in biometric sensor. Biometric data never leaves your device.
• One-time password: Authenticator apps such as Google Authenticator that generate rotating codes.
• Email: One-time codes sent to your email.
• Phone: One-time codes via SMS or voice call.
• Recovery code: One-time backup codes for emergency access when your primary method is unavailable.

Setting up MFA: Add an authentication method from your profile’s security settings, and save your recovery codes in a safe place. Treat recovery codes like passwords—anyone who has them can bypass your MFA.

MFA enforcement

Workspace administrators configure MFA from Settings > Security:

• MFA enforced: When enabled, multi-factor authentication is required when users log in to the workspace.
• Allowed MFA methods: Choose which of the methods above users may register.
• MFA timeout: How long an MFA verification stays valid before it must be repeated (default 15 minutes, configurable from 1 minute to 1 day).
• Require MFA for: Require a fresh MFA verification before specific privileged actions (for example, running as a system account, or running Deploy shell as a root account).

Step-up authentication

For sensitive operations, Alpacon can require a fresh MFA verification even if you’re already logged in. This is controlled by the Require MFA for settings and the MFA timeout described above.

Actions that can require step-up MFA

Workspace administrators choose which actions require a fresh MFA check under Require MFA for:

• Running Websh, WebFTP, command execution, or the code editor as a system account
• Running Deploy shell as a root account
• Server actions

Privilege elevation (sudo) is handled separately through the sudo-with-MFA approval flow.

How it works:

1. Initial login: Authenticate with password + MFA
2. Privileged action: Attempt a protected action
3. Step-up prompt: Re-verify with MFA (if the MFA timeout has elapsed)
4. Time-limited: The verification stays valid for the MFA timeout (default 15 minutes, configurable)
5. Auto-expire: Must re-verify after the timeout

Example flow:

User logs in → [Password + MFA] → Access granted (standard permissions)
                      ↓
User clicks "Connect to prod-db-01 as root"
                      ↓
Step-up authentication required → [MFA verification]
                      ↓
Privileged access granted (15 minutes)

Security benefits:

• Prevents session hijacking: Stolen sessions cannot access privileged resources
• Limits blast radius: Compromised accounts have limited damage potential
• Audit trail: Clear distinction between regular and privileged access
• Compliance: Meets requirements for privileged access management (PAM)

Best practices:

• Keep step-up timeout short (15 minutes or less)
• Require hardware keys or biometrics for privileged access
• Enable notifications for all step-up authentications
• Regularly review privileged access logs

Single sign-on (SSO)

💎 Available in Enterprise plan

Integrate with your organization’s identity provider:

Supported protocol

SAML 2.0

• Industry-standard federation protocol
• Compatible with Azure AD, Okta, OneLogin, Google Workspace, and other SAML identity providers
• Just-in-time (JIT) user provisioning
• Centralized user management

SSO configuration

1. In your identity provider:

   • Create a new SAML application
   • Configure the ACS (Assertion Consumer Service) URL and entity ID
   • Set up attribute mapping (email, name, groups)

2. In Alpacon:

   • Add the SAML connection in your workspace settings (Enterprise plan, superuser only)
   • Enter the IdP metadata or configure it manually
   • Map IdP groups to Alpacon user groups (optional)
   • Test the SSO connection

3. User experience:

   • Users click “Sign in with SSO”
   • Redirect to company IdP login page
   • After authentication, redirect back to Alpacon
   • Automatic account creation with JIT provisioning

SSO features

• Automatic provisioning: Create users automatically on first login
• Group sync: Map IdP groups to Alpacon user groups
• Deprovisioning: Remove access when user is removed from IdP
• Session management: Respect IdP session policies
• Force SSO: Require all users to authenticate via SSO

API tokens & service tokens

For programmatic access and automation:

API tokens

• Tokens for CLI and API access, created under Preferences > API tokens
• Granular per-resource scopes (read/write/owner) plus command and server ACL rules
• Choose an expiration or no expiration
• Revocable at any time

Creating an API token:

# Via web interface: Preferences > API tokens > New API token
 
# Using the token
export ALPACON_TOKEN="your-token-here"
alpacon server list

Applications & service tokens

Applications are non-human identities for automation. Each application issues service tokens that inherit the application’s role and permissions:

• Not tied to individual users
• Permissions defined by the application’s role and scopes
• Activity logged per token

Use cases:

• CI/CD pipelines
• Monitoring integrations
• Automated deployments
• Third-party tool integrations

Access control

Role-based access control (RBAC)

Alpacon uses a role-based permission system with both built-in roles and custom roles.

Built-in roles

Built-in roles are automatically assigned based on the user’s role setting:

1. Member (regular user) → no workspace-wide RBAC role

• Not given a workspace-wide built-in role; access comes from group membership and any roles explicitly assigned
• Access only to assigned servers and resources
• Cannot modify workspace settings
• Cannot invite other users

2. Staff → RBAC role: admin

• Administrative privileges
• Can manage servers and users
• Can configure user groups
• Can view audit logs
• Cannot modify workspace billing or delete workspace

3. Superuser → RBAC role: superuser

• Full administrative access
• Can modify all workspace settings
• Can manage billing and subscriptions
• Can delete workspace
• Can promote/demote other users

Setting a user to Staff automatically assigns the RBAC admin role, and setting a user to Superuser automatically assigns the superuser role.

Custom roles

In addition to built-in roles, Superuser members can create and manage custom roles with fine-grained permissions:

• Permission format: Each permission follows the resource:action format (e.g., server:read, server:write)
• Global scope: Permissions apply to all objects of the resource type
• Object scope: Permissions can be limited to specific resource types and objects

Custom roles can be assigned to individual users or groups. When a role is assigned to a group, all members of that group inherit the role’s permissions.

For managing roles, see Workspace settings > Roles.

Resource-scoped roles

Resource-scoped roles are automatically assigned when a user becomes an owner or manager of a specific resource (e.g., group:owner, server:owner).

Permission matrix

✓ Full access · △ Limited access (read-only) · ✗ No access

User groups

User groups enable efficient permission management:

Benefits:

• Assign permissions to multiple users at once
• Organize users by team, department, or role
• Dynamic access control (add user to group → instant access)
• Easier audit and compliance

Group configuration:

# Example: DevOps team group
name: "DevOps Team"
description: "Production infrastructure access"
servers:
  - production-web-*
  - production-db-*
  - production-cache-*
permissions:
  terminal: true
  webftp: true
  deploy_shell: true
  sudo: true

Role inheritance: When a role is assigned to a group, all members of that group inherit the role’s permissions. A user’s effective permissions are the union of all directly assigned roles and group-inherited roles.

Best practices:

• Create groups based on job functions, not individuals
• Use naming conventions (e.g., team-devops, team-security)
• Regular group membership reviews
• Document group purposes and access levels

Server-level access control

Fine-grained control over server access:

User assignment

• Direct assignment: Assign specific users to servers
• Group assignment: Assign groups to servers (recommended)
• Wildcard matching: Use patterns to assign access (e.g., web-*, *-prod)

Work session scopes

To use a server, a user requests a time-bound work session scoped to the specific actions they need:

• Web terminal: Browser terminal access (Websh)
• File transfer: Upload and download files (WebFTP)
• Execute commands: Run commands across servers
• Code editor: Edit files in the browser
• Port forwarding: Tunnel to a service on the server
• Privilege elevation: sudo, gated by the sudo-with-MFA policy

What a user may request is bounded by their RBAC roles and group membership.

Temporary access

Grant time-limited access to servers:

# Temporary access configuration
user: john@company.com
server: production-db-01
access_level: full
duration: 4h
reason: "Emergency database recovery"
approval_required: true
approver: alice@company.com

Features:

• Automatic expiration (1 hour to 30 days)
• Approval workflow (optional)
• Audit trail with reason
• Notification before expiration
• Automatic revocation after expiration

Session management

Session security

• Work session expiry: Access is granted through time-bound work sessions that expire automatically
• Websh session timeout: The browser terminal retains its session for a configurable window (15 minutes to 1 day)
• Remote session termination: Users or admins can end active sessions at any time

MFA validity

After you complete MFA, the verification stays valid for the workspace’s MFA timeout (default 15 minutes) before you’re prompted again. Actions under Require MFA for trigger a fresh check once the timeout has elapsed.

Network security benefits

Alpacon’s gateway-based architecture provides significant network security advantages over traditional SSH access:

Zero open ports

No inbound ports required:

• Servers never expose SSH (port 22) or any other ports to the internet
• Alpamon agent initiates outbound-only connections to Alpacon Gateway
• All connections flow through encrypted WSS (WebSocket Secure) over HTTPS

Attack surface elimination:

• No network scanning: Attackers cannot discover your servers through port scanning
• No SSH brute force: SSH port is never exposed, eliminating brute force attack vectors
• No direct access: Servers are invisible to external attackers

Protection against lateral movement

Isolated server connections:

• Each server connects independently to the gateway
• Servers cannot directly communicate with each other through Alpacon
• Compromising one server doesn’t grant access to others via Alpacon connections

Prevents internal attack propagation:

• Even if an attacker gains access to one server, they cannot use Alpacon to pivot to other servers
• Gateway enforces authentication and authorization for every connection
• No server-to-server trust relationships through Alpacon

Centralized security enforcement

Gateway as security checkpoint:

• All traffic flows through Alpacon Gateway, so access is authenticated and authorized centrally
• Sessions and commands are recorded and risk-scored (AI risk analysis runs after a session ends)
• Centralized access control eliminates per-server security configuration
• Immediate revocation of access across all servers

Defense in depth:

• Multiple layers of authentication (password/SSO + MFA + step-up authentication)
• Network-level isolation (no open ports) + Application-level security (IAM, RBAC)
• Continuous monitoring and audit logging

Comparison with traditional SSH

IP allowlisting

🚧 Coming Soon - This feature will be available in Essentials plan or higher

IP allowlisting will allow you to restrict access to specific IP addresses or ranges for enhanced security:

Planned features

Workspace-level IP allowlist:

• Restrict workspace access to specific IP ranges (office networks, VPN gateways, etc.)
• Multiple enforcement modes (required, optional, disabled)
• Support for CIDR notation for flexible IP range configuration

Server-level IP allowlist:

• Apply IP restrictions to individual servers
• Perfect for production database servers requiring additional protection
• Override workspace-level settings per server

Dynamic IP management:

• Emergency bypass with admin approval for urgent access
• IP rotation support using CIDR ranges
• VPN gateway integration

Use cases:

• Lock down production environments to office IPs only
• Require VPN connection for sensitive servers
• Prevent unauthorized access from unknown locations
• Compliance with network security policies

Timeline: IP allowlisting is currently in development. Contact support@alpacax.com if you need this feature for your organization.

Audit logging

Comprehensive logging of authentication and access events:

Logged events

Authentication:

• Login attempts (success and failure)
• Logout events
• MFA verification
• Password changes
• SSO authentication

Authorization:

• Permission changes
• Role assignments
• Group membership changes
• Access denials

Resource access:

• Server connections
• Terminal session creation
• WebFTP file operations
• API calls

Log retention

• Default: 90 days
• Enterprise: Up to 5 years
• Immutable logs (tamper-proof)
• SIEM integration (coming soon)

Reviewing audit activity

Review audit activity from the CLI with alpacon audit:

# Recent audit activity
alpacon audit --tail 50
 
# Filter by user
alpacon audit --user john@company.com
 
# Filter by application and model
alpacon audit --app cert --model authority

Data privacy & workspace isolation

Alpacon is built with privacy and data isolation as core principles:

Complete workspace isolation

Each workspace operates in a fully isolated environment:

• Data segregation: Workspace data is completely separated at the database and application level
• No cross-workspace access: Users in one workspace cannot access or view data from other workspaces
• Isolated authentication: User accounts and permissions are workspace-specific
• Network isolation: Each workspace has isolated network policies and access controls

Zero access by platform administrators

Your data is yours, and only yours:

• No admin access: AlpacaX platform administrators cannot access workspace data
• Encrypted at rest: All workspace data is encrypted with workspace-specific encryption keys
• Audit trail privacy: Only workspace administrators can view audit logs
• Server credentials: Server connection credentials are encrypted and inaccessible to platform admins
• Zero knowledge: Platform administrators cannot see your server commands, files, or configurations

What AlpacaX admins can access:

• Platform infrastructure and operations
• System-level logs (not workspace-specific data)
• Aggregate usage metrics (anonymized)
• Billing and subscription information

What AlpacaX admins cannot access:

• Workspace server data or configurations
• User activity within workspaces
• Terminal session contents or recordings
• API keys or service account credentials
• Server access logs or audit trails

Instant data deletion

When you delete your workspace, your data is immediately removed:

Deletion process:

1. Immediate (within seconds):

   • All server connections terminated
   • All active sessions closed
   • All workspace users logged out
   • Workspace marked for deletion

2. Complete removal (within minutes):

   • All server credentials deleted
   • All audit logs removed
   • All user data erased
   • All configuration settings deleted
   • Encryption keys destroyed

3. Permanent deletion (within 24 hours):

   • All backups purged
   • All database records permanently deleted
   • No recovery possible after deletion completes

No grace period: Unlike some platforms, Alpacon does not retain your data after workspace deletion. Once you confirm deletion, the process is irreversible.

Data ownership

• You own your data: All data in your workspace belongs to you
• No data mining: We don’t analyze or use your data for any purpose other than providing the service
• Export anytime: Export all your data at any time in standard formats
• No vendor lock-in: Complete data portability ensures you can migrate at any time

Best practices

For administrators

1. Enforce MFA: Require MFA for all users, especially admins
2. Use groups: Manage permissions via groups, not individual users
3. Least privilege: Grant minimum necessary permissions
4. Regular reviews: Audit user access quarterly
5. Monitor logs: Set up alerts for suspicious activities
6. SSO integration: Use SSO for centralized user management (Enterprise)
7. Hardware MFA: Consider restricting to hardware keys or biometric authentication for high-security environments

For users

1. Strong passwords: Use a password manager and unique passwords
2. Enable MFA: Protect your account with multi-factor authentication
3. Review sessions: Regularly check and terminate old sessions
4. Report suspicious activity: Immediately report unusual login alerts
5. Secure tokens: Never share API tokens or commit them to code

Related documentation

• Security overview - Overall security approach
• IAM management - Detailed IAM configuration guide
• User Groups - Managing user groups
• Audit Logs - Viewing and analyzing audit logs

Contact

For authentication and access control inquiries:

• Email: security@alpacax.com
• Support: support@alpacax.com

Last updated: November 2025