Skip to main content

Panel and Interface (Administrator Guide)

The GuardianKey Auth Bastion Enterprise panel, accessed through the GDN Cyber Security Platform, centralizes all administration, monitoring, and configuration features for the bastion.

All options are organized in the left sidebar menu under “GK Auth Bastion”. This section provides a practical guide for administrators, explaining the purpose and usage of each panel item.

📌 TOC (Table of Contents)​

🧩 Core Concepts​

Before configuring GuardianKey Auth Bastion Enterprise, it is important to understand the logical structure of the tool. Understanding these concepts will allow you to create an organized, scalable, and secure authentication architecture.

Below, we explain the main elements and how they relate:

🏢 Organization​

The Organization is the highest level of the structure. It represents a logical entity or client within the platform. All bastion configuration (domains, authgroups, users, tokens, policies) is within the organization's scope.

Features:​

  • Each organization can have multiple domains and authgroups.
  • You can have multiple bastions (nodes) operating in high availability or load balancing within the same organization.
  • Integrations with external modules (GovBR, GKAS, GKTinc) are also done per organization.

Example: In a multi-client environment, each client can have its own Organization, logically isolated.

🌐 Domain Name​

The Domain Name represents the FQDN (fully qualified domain name) that will be protected by the bastion.

Features:​

  • Can be a domain (e.g., company.com) or subdomain (e.g., sso.company.com).
  • The bastion listens on the defined port (e.g., 443) for this domain.
  • Can use a manual certificate (uploaded by the administrator) or Let's Encrypt (automatic renewal).
  • Must be linked to at least one Authgroup to be functional.

Important: Domains without linked authgroups have no protection logic and are not operational.

🔐 Authgroup​

The Authgroup represents an authentication unit — usually a protected system or service.

Features:​

  • Each authgroup is linked to a single domain.
  • Can protect multiple paths within the domain (e.g., /system1, /system2).
  • Defines:
    • Protected paths
    • Authentication type (TOTP, email, GovBR, etc.)
    • Registration method (email, password, API, etc.)
    • Token TTL and path
    • External integrations (GovBR, GKAS, GKTinc)
  • Routing to the target system is done via a list of backend servers.

Example: In the domain client.com, you can have:

  • Authgroup "System 1" protecting /system1
  • Authgroup "System 2" protecting /system2

Note: You cannot use the same authgroup in more than one domain. To do so, you must duplicate the configuration in another authgroup.

🧑‍🤝‍🧑 User Pool​

The User Pool allows sharing 2FA users between different authgroups.

Features:​

  • If two or more authgroups are linked to the same user pool, 2FA users are shared among them.
  • Allows applying a unified MFA policy across multiple systems.
  • Can be edited at any time, with no security impact.

Example: If user "[email protected]" registers in the authgroup for System A, they can authenticate in System B without a new registration, as long as both share the same User Pool.

🔁 Backend Servers​

Backend Servers are the destinations to which the bastion forwards the request after authentication is validated.

Features:​

  • Can be one or more IPs/hosts (one per line).
  • Load balancing is done via round-robin.
  • Supports HTTP or HTTPS backends, of any technology (PHP, Node, Java, etc).

Example: An authgroup can redirect authenticated users to http://10.0.1.20:8080, http://10.0.1.21:8080, etc.

🔑 Token Path and Token TTL​

Token Path and Token TTL define how the bastion manages a user's authenticated session.

Token Path:​

  • Defines which URL the session token will be valid for.
  • Prevents token reuse on other routes.

Token TTL:​

  • Defines the session token validity period (e.g., 30 minutes, 2 hours).
  • After expiration, the user must go through 2FA again.

Important: TTL applies only to the session, not to the TOTP code.

🔐 Authentication Types​

You can choose the authentication and registration method for 2FA users:

  • Authentication types:

    • TOTP: standard via authenticator app.
    • E-mail: code sent to the user's email.
    • Bastion: full control via bastion.
    • GovBR: login via OAuth2.
    • Disabled: disables authentication.

  • Registration (onboarding) methods:

    • E-mail: user registers using their email.
    • Credentials: user provides login/password and the bastion validates in the protected system.
    • API: direct integration with an external system for validation.
    • Bastion: bastion controls the entire process.

🧱 Logical Structure (Summary)​

Organization
 └── Domain Name(s)
    └── Authgroup(s)
         ├── Protected paths
         ├── Backends
         ├── Auth method
         ├── Token policy
         └── (optional) External integrations

This logical structure summarizes the main hierarchy of GuardianKey Auth Bastion, making initial planning and configuration easier. Ensure each element is properly configured to guarantee the solution's security and proper operation.

📊 Dashboards​

Purpose: Monitor the solution's activity and status in real time.

  • Bastion Events: time graph with events classified as:
    • info (green): normal operational events.
    • warn (yellow): atypical situations that did not prevent operation.
    • error (red): critical failures or blocks.
  • Authentication Event Levels: overview of event levels (pie chart).
  • Top Users / IPs / Types / Status: useful rankings to identify abuse or spikes.

🔧 Recommended actions:

  • Use advanced filters to analyze specific periods.
  • Click "Show/hide filter panel" to refine data.
  • Export reports (Excel, CSV, PDF) for auditing or management.

👤 Users (2FA Users)​

Purpose: Manage users who will use two-factor authentication.

Main screen:​

  • Displays all users with 2FA enabled.
  • Columns: ID, Authgroup, Username, Email, Creation date, TOTP status.

Actions:​

  • Edit/View: allows changing the TOTP status:
    • not set: no TOTP.
    • active: TOTP active.
    • validated: TOTP confirmed.
    • inactive: TOTP deactivated.
    • renew: force new TOTP registration.
  • Delete: removes the user from 2FA.

📌 Important: to "reset" a TOTP, just change its status to renew.

🔑 Auth Tokens​

Purpose: View and manage session tokens generated after 2FA.

Main screen:​

  • List of active tokens.
  • Columns: ID, Authgroup, Username, User ID, TTL, Created, Updated.

Actions:​

  • Edit: view and change:
    • TTL (session lifetime)
    • Allowed IPs
  • Delete: forces token expiration.

🛡️ Best practice: use Allowed IPs to limit token reuse to authorized IPs only.

📁 Explore Events​

Purpose: Investigate and audit events in detail.

Screen:​

  • Shows all events generated by the solution.
  • Columns: Date/time, Authgroup, Username, IP, Type, Status, Level, Detail.

🔍 Usage tips:

  • Use the "search" field to find specific terms (in any column).
  • Filtering can be done by any field.
  • For larger exports, contact GuardianKey support.

⚙️ Settings​

Purpose: Perform central configuration of the solution. This is the most sensitive part of the panel.

🌐 Domain Names​

Register domains monitored by the bastion.

  • Each table row represents a protected domain (FQDN).
  • Allows choosing certificate method:
    • Let's Encrypt (automatic renewal)
    • Manual (client uploads the certificate)

📥 To add:

  1. Click “Add new row”.
  2. Fill in the data, including certificate (or leave blank for self-signed).

🔒 Auth Groups​

Authentication groups per system (e.g., system1, system2, etc.)

  • Relate domains, paths, and 2FA methods.
  • Allows defining:
    • Protected paths
    • Authentication backends (automatic load balancing)
    • Authentication type (email, TOTP, GovBR, etc.)
    • User registration method
    • Token TTL
    • Integration endpoints with legacy systems
    • User sharing with “User Pool”

💡 Important:

  • Each authgroup defines how 2FA works in a system.
  • You can have multiple authgroups in the same domain, protecting different systems.

🔌 GK Integrations​

Integrations with advanced GuardianKey modules.

  • GK Auth Security: adds risk analysis based on score.
  • GK TINC: applies cryptographic challenges against bots.

📌 To activate:

  • Fill in the ID, key, and IV fields as provided by the integration.

🧩 Templates​

Customize the HTML of bastion messages and screens.

  • Emails: support dynamic variables (e.g., {{username}}, {{token}}).
  • Bastion screens: static (do not support dynamic variables).

📝 Tip: use to adapt your company's visual communication.

📧 E-mail Settings​

Configure the solution's email sending (OTP, registration, notifications).

  • Define:
    • Subjects and allowed domains per email type.
    • SMTP (host, port, method, authentication).
  • Use the test button to validate settings.

🌍 Firewalling​

Restrict access by country (geo-restriction).

  • Available modes:
    • Disabled
    • Allow only selected countries
    • Deny only selected countries

📌 Displayed by country name (not ISO code).

🆔 GovBR Integration​

Configures GovBR authentication for main login (not 2FA).

  • Defines:
    • Environment (staging / production)
    • OAuth2 Client ID and Secret
    • Endpoint and injection script for "login with GovBR" button

📌 Important: for multiple environments, create one authgroup per environment.

📜 Audit Logs​

Displays all changes made to bastion settings.

  • Useful for tracking administrative changes.

👤 User Policies​

Rules applied to specific users.

  • Allows creating exceptions or adjusting TTL individually.
  • Example: temporarily disable 2FA for an admin.

📌 Priority: IP rules take precedence over user rules.

🌐 IP Policies​

Rules by IP/CIDR.

  • Ideal for whitelisting corporate networks.
  • Useful for exempting specific machines from 2FA requirement.

✅ Best Practices for Administrators​

  • Periodically review registered authgroups and domains.
  • Use dashboards to detect access anomalies.
  • Use User Policies and IP Policies sparingly.
  • Enable integrations with GKAS and GKTinc for maximum security.
  • Document and review changes based on audit logs.

📘 Additional Documentation​

For details on access permissions, platform user management, and integration with other GuardianKey solutions, visit:

👉 guardiankey.io/docs/gdn