Authentication & access control

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

Authentication infrastructure

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

The default authentication method for all users:

• Email/password login: Traditional authentication with email and password
• Social login: Sign in with Google account for faster access

Password requirements:

• Minimum 8 characters (12+ recommended)
• Must include uppercase, lowercase, numbers, and special characters
• Cannot reuse last 5 passwords
• Password expiration (optional, configurable by workspace admins)

Password security:

• Stored using bcrypt with adaptive cost factor
• Salted hashing prevents rainbow table attacks
• Rate limiting on failed login attempts (5 attempts per 15 minutes)
• Account lockout after 10 consecutive failed attempts

Multi-factor authentication (MFA)

MFA adds an additional layer of security to user accounts:

Supported MFA methods

Alpacon supports multiple MFA methods to balance security and convenience:

1. Hardware security keys (most secure)

• Support for FIDO2/WebAuthn hardware keys (YubiKey, Titan Key, etc.)
• Phishing-resistant and tamper-proof
• Strongest authentication method
• Recommended for high-security environments

2. Biometric authentication

• TouchID, FaceID, Windows Hello
• Convenient and secure
• Biometric data never leaves your device
• Hardware-backed security

3. Time-based one-time password (TOTP)

• Compatible with authenticator apps (Google Authenticator, Authy, 1Password, etc.)
• 6-digit codes that rotate every 30 seconds
• Works offline
• Widely supported

Setup process:

1. Navigate to Settings > Security > Multi-Factor Authentication
2. Click Enable MFA
3. Choose your preferred method (Hardware Key, Biometric, or TOTP)
4. Follow the setup instructions for your chosen method
5. Save recovery codes in a secure location

4. Email-based OTP

• Receive one-time codes via email
• Convenient for users without other devices
• Available as backup method

5. SMS-based OTP

• Receive one-time codes via SMS
• Less secure than other methods (vulnerable to SIM swapping)
• Available as backup method only

6. Recovery codes

• One-time use backup codes generated during MFA setup
• Each workspace generates 10 recovery codes by default
• Use when primary MFA method is unavailable (lost device, no phone signal, etc.)
• Store in a secure location (password manager, safe, etc.)
• Each code can only be used once
• New codes can be regenerated at any time (invalidates old codes)

When to use recovery codes:

• Lost or broken hardware security key
• Phone with authenticator app is unavailable
• Cannot receive SMS messages
• Biometric device malfunction
• Emergency access situations

Important: Treat recovery codes like passwords. Anyone with access to your recovery codes can bypass your MFA protection.

MFA enforcement policies

Workspace administrators can configure MFA requirements:

# Workspace security policy
mfa_policy:
  enforcement: "required"  # none, optional, required, required_for_admins
  grace_period_days: 7     # Days to enable MFA after account creation
  trusted_devices: true    # Remember device for 30 days
  recovery_codes: 10       # Number of recovery codes to generate
  allowed_methods:         # Restrict MFA methods (superuser control)
    - hardware_key         # YubiKey, Titan, etc.
    - biometric           # TouchID, FaceID, Windows Hello
    - totp                # Authenticator apps

Enforcement levels:

• None: MFA is disabled for the workspace
• Optional: Users can choose to enable MFA
• Required for admins: Staff and superusers must use MFA
• Required: All users must enable MFA to access workspace

MFA method restrictions (superuser only):

Workspace superusers can restrict which MFA methods are allowed, enforcing hardware-backed security:

• Hardware keys only: Require YubiKey, Titan Key, or other FIDO2 devices (most secure)
• Biometric only: Require TouchID, FaceID, or Windows Hello (high security, convenient)
• Hardware + biometric: Allow only hardware-backed methods (recommended for compliance)
• All methods: Allow TOTP authenticator apps as well (less secure but more accessible)

Why restrict MFA methods?

Hardware keys and biometric authentication provide stronger security than software-based TOTP:

• Phishing-resistant: Hardware keys cannot be phished or stolen remotely
• No screenshots: Biometric data never leaves the device
• Tamper-proof: Hardware security prevents malware attacks
• Compliance: Many regulations prefer or require hardware-backed authentication

Step-up authentication

💎 Available in Enterprise plan

For sensitive operations, Alpacon requires additional authentication even if you’re already logged in:

When additional authentication is required

Privileged server access:

• Connecting to servers as a privileged user (root, sudo access)
• Using Websh with elevated permissions
• Accessing WebFTP with write permissions to sensitive directories
• Executing Deploy Shell commands

Administrative actions:

• Modifying workspace security settings
• Inviting or removing users
• Changing user roles and permissions
• Accessing audit logs

How it works:

1. Initial login: Authenticate with password + MFA
2. Privileged action: Attempt to access privileged resource
3. Step-up prompt: Re-authenticate with MFA (even if recently logged in)
4. Time-limited: Elevated session lasts 15 minutes (configurable)
5. Auto-expire: Must re-authenticate after 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 protocols

SAML 2.0

• Industry-standard federation protocol
• Compatible with Azure AD, Okta, OneLogin, Google Workspace, etc.
• Just-in-time (JIT) user provisioning
• Centralized user management

OAuth 2.0 / OpenID Connect

• Modern authentication protocol
• Support for Google, Microsoft, GitHub, and custom providers
• Faster setup than SAML
• Mobile-friendly authentication

SSO configuration

1. In your identity provider:

   • Create a new SAML/OAuth application
   • Configure redirect URLs and entity IDs
   • Set up attribute mapping (email, name, groups)

2. In Alpacon:

   • Navigate to Settings > Authentication > SSO
   • Choose protocol (SAML or OAuth)
   • Enter IdP metadata URL or manually configure
   • Map IdP groups to Alpacon user groups (optional)
   • Test 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 keys & service accounts

For programmatic access and automation:

Personal access tokens (PAT)

• Long-lived tokens for CLI and API access
• Scoped permissions (read-only, write, admin)
• Expiration dates (30 days, 90 days, 1 year, no expiration)
• Revocable at any time

Creating a PAT:

# Via web interface: Settings > API Keys > Create New Token
 
# Using the token
export ALPACON_TOKEN="your-token-here"
alpacon server list

Service accounts

💎 Available in Essentials plan or higher

• Dedicated accounts for automation and integration
• Not tied to individual users
• Specific permission scopes
• Audit trail for service account actions

Use cases:

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

Access control

Role-based access control (RBAC)

Alpacon uses a hierarchical permission system:

User roles

1. User (regular user)

• Default role for all workspace members
• Access only to assigned servers and resources
• Cannot modify workspace settings
• Cannot invite other users

2. Staff

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

3. Superuser

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

Permission matrix

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

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)

Access levels

1. No access

• User cannot see or access the server

2. Read-only

• View server information and metrics
• Cannot create terminal sessions
• Cannot use WebFTP

3. Terminal access

• Create and use terminal sessions
• Execute commands on the server
• Cannot use sudo (unless explicitly granted)

4. Full access

• Terminal access with sudo privileges
• WebFTP file upload/download
• Deploy Shell execution
• Restart Alpamon agent

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

• Automatic timeout: Sessions expire after 12 hours of inactivity (configurable)
• Concurrent session limit: Maximum 5 active sessions per user
• Device tracking: Track active sessions by device and location
• Remote session termination: Users or admins can terminate sessions remotely

Trusted devices

Users can mark devices as trusted:

• Remember device for 30 days
• Skip MFA on trusted devices (if enabled in policy)
• View and manage trusted devices in settings
• Revoke trust at any time

Security considerations:

• Trusted devices still require password
• Don’t enable on shared computers
• Automatically invalidated on password change

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 for inspection and policy enforcement
• Real-time threat detection and blocking
• 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)

Audit reports

Generate compliance reports:

# User access report
alpacon audit report --type user-access --user john@company.com --period 30d
 
# Failed login attempts
alpacon audit report --type failed-logins --period 7d
 
# Permission changes
alpacon audit report --type permission-changes --since 2025-10-26

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 password manager and unique passwords
2. Enable MFA: Protect your account with multi-factor authentication
3. Trusted devices: Only mark personal devices as trusted
4. Review sessions: Regularly check and terminate old sessions
5. Report suspicious activity: Immediately report unusual login alerts
6. 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