Skip to main content

Use Cases

Below are practical examples of how GuardianKey Auth Bastion Enterprise can be configured for different web system protection scenarios. Each use case provides a brief description, the protection objective, the expected authentication flow, and recommended bastion settings.

⚠️ Important: Each implementation may vary according to the technical characteristics of the protected system. The GuardianKey Customer Success team is available to support configuration and integration decisions.

Table of Contents​

🧩 Case 1: System with email-based login (2FA with TOTP)​

Description​

Web system where the user authenticates with email and password. The goal is to protect access by adding two-factor authentication (2FA) with TOTP (e.g., Google Authenticator).

Objective​

Add MFA before the login form, without changing the system.

Flow​

User accesses /login → Bastion requires TOTP → If valid, shows form → Authentication in the system

Bastion Configuration​

  • Auth Type: TOTP
  • Registration Method: email
  • Token Path: /login
  • Token TTL: 3600
  • User Pool: optional
  • Backends: http://10.0.0.10:8080

📌 Tip: No external API is needed, as the bastion uses the email as the main identifier.

🧩 Case 2: System with username different from email (2FA with credential validation)​

Description​

System where login uses a custom identifier (e.g., registration number, nickname, etc.). 2FA protection will use TOTP, but the bastion needs to validate the user's identity to allow second factor registration.

Objective​

Protect access with MFA and validate identity before registering 2FA.

Flow​

Bastion Configuration​

📌 Tip: The bastion will observe the original login response to check if the credentials are correct. The API can return 200 OK or a specific field in the response body.

🧩 Case 3: Authentication with GovBR (CPF as identifier)​

Description​

Public web system where login is based on CPF. The goal is to replace local login with authentication via GovBR (OAuth2).

Objective​

Use GovBR federated identity as the main authentication method.

Flow​

User accesses system → Bastion displays "Login with GovBR" button → Login via OAuth2 → CPF received → Redirect to authenticated application

Bastion Configuration​

  • Auth Type: GovBR
  • Registration Method: Disabled
  • GovBR Integration:
    • Client ID / Secret / Endpoint provided by GovBR
    • Customizable JavaScript for button injection
  • Token TTL: 3600
  • User Pool: optional

📌 Requirement: The protected system must have the user's CPF for post-login correlation.

🧩 Case 4: API-only integration (without GDN panel)​

Description​

Corporate environment that manages users and 2FA exclusively via REST API, without using the bastion's graphical interface.

Objective​

Automate 2FA provisioning and validation directly in the backend.

Flow​

System calls API /register-user → User receives TOTP key → App reads QR Code → Validates code via API /verify → Access granted

Endpoints used (fictitious example)​

  • POST /api/users/register 
    { "username": "joao", "email": "[email protected]" }
  • GET /api/users/joao/totp → Returns QR Code
  • POST /api/users/joao/verify 
    { "totp": "123456" }

Bastion Configuration​

  • Auth Type: TOTP
  • Registration Method: API
  • Data Integration Endpoint - Auth: https://meusistema.local/api/verify
  • User Pool: required (for correlation via API)
  • Panel: not used in this scenario

📌 Note: Ideal for systems with their own panel or integration with existing portals.

🧩 Case 5: Multiple systems on the same domain with shared users​

Description​

Company with several systems hosted under the same domain (e.g., /erp, /hr, /portal) and wants to protect all with shared 2FA.

Objective​

Apply MFA to multiple services reusing the user base.

Flow​

User accesses /erp/login → Bastion validates TOTP → Redirects to ERP  
User accesses /hr/login → TOTP already active → Redirects directly

Bastion Configuration​

  • Create an authgroup per system (e.g., ERP, HR, Portal).
  • Use the same User Pool for all.
  • Define specific Token TTL and Token Path per system.
  • Configure Backend per service.

📌 Tip: The 2FA token can be reused while within the TTL.

🧩 Case 6: User with custom policy (whitelist or special TTL)​

Description​

Scenario where a specific user must have different behavior from others, such as:

  • 2FA exemption (whitelist).
  • Session with extended TTL.

Objective​

Apply granular control based on user profile.

Bastion Configuration​

  1. Access User Policies.
  2. Add a new row:
    • Authgroup: Portal
    • Username: admin01
    • Action: Whitelist or Token TTL = 14400 (4h)

📌 Note: IP policies (IP Policies) take precedence over user policies.

🧩 Case 7: Policy by IP (allowing trusted networks)​

Description​

Company wants to exempt 2FA requirement for accesses originating from an internal network or trusted fixed IP.

Objective​

Reduce friction for internal users while maintaining external security.

Bastion Configuration​

  1. Access IP Policies.
  2. Add a new row:
    • Authgroup: Intranet
    • CIDR: 192.168.0.0/24
    • Action: Whitelist

📌 Best practice: Combine with Firewalling to restrict countries of origin and strengthen external security.

📘 Conclusion​

The presented cases demonstrate the flexibility and ease of adoption of GuardianKey Auth Bastion Enterprise in different contexts. Whether focusing on MFA, federated login via GovBR, API automation, or granular policy control, the solution enables robust and scalable web application protection.

For support at any stage of integration, count on the GuardianKey Customer Success team.