Technical Specifications
Below are the technical specifications of GuardianKey Auth Bastion Enterprise, detailing its main features, which can be used for comparison with other solutions.
Table of Contents
- Technical Specifications
General Specifications
GuardianKey Auth Bastion focuses on protecting systems against unauthorized access.
The system consists of the following parts: i) Bastion acts as a reverse proxy for protected applications, intercepting requests and implementing protection layers; ii) Controller processes events and maintains the database and configurations; iii) Web administration console allows system configuration and event visualization.
GuardianKey Auth Bastion offers the following security features that can be configured to protect web systems: i) Implementation of two-factor authentication (2FA) without needing changes to the protected system; ii) Integration of protected applications with login to the authenticator via OAuth2/OIDC protocol; iii) Blocking access from predefined countries;
The system allows protection of multiple web systems from the same Bastion, enabling user segmentation and security policies per protected system.
Security policies can be configured by path of the protected system.
When accessing an application protected by GuardianKey Auth Bastion, the system intercepts the request and proceeds according to the configurations defined by the administrator via the web administration console.
Security policies can be configured by Authgroup, which is a security policy that can be applied to one or more paths of a protected application URL.
The system supports Second Factor First Authentication (SFFA), requiring second-factor authentication before accessing the login form of the protected system, providing greater protection and simpler implementation.
Authentication methods can be defined per Authgroup:
- TOTP via app - second-factor authentication via authenticator app, RFC 6238 compatible, such as Google Authenticator;
- OTP via email - authentication by sending a one-time code (second factor) via email;
- OTP via integration - authentication by sending a one-time code (second factor) via POST to a configurable endpoint, usable for channels like Telegram, SMS, etc.;
- OAuth2/OIDC - authentication via OAuth2/OIDC systems, such as GovBR.
- Custom (Bastion) - authentication customizable via LUA code.
- API Interaction (Disabled) - allows a protected application to interact with GuardianKey Auth Bastion via API for cryptographic code generation, OTP validation, event logging, and other features.
For solution screens, integration is supported with:
- GuardianKey Auth Security - integration for OTP validation and user registration to generate QR Codes, protecting against authentication attacks;
- GuardianKey GKTinc - integration in submitted forms to deter brute-force and automated access attempts.
The system logs configuration change audits performed via the web administration console for entities: policies (Authgroup), protected URLs (Domain names), user policies, IP policies, users, and tokens.
Organizations can be created, each containing multiple authentication groups (Authgroups) and protected URLs (Domain names), enabling user and security policy segmentation per organization.
One or more backends (application servers) can be defined for each Authgroup.
For session control, authentication tokens are generated by Bastion and sent to the user's browser. The system administration allows setting token TTL and validity path.
Tokens are signed with a cryptographic key configured in the Authgroup, which can be used by the protected application to validate token authenticity.
Token information includes:
- Username: authenticated user's name;
- Auxiliary tokens: auxiliary tokens, when applicable, e.g., for OAuth2/OIDC integrations;
- Allowed IPs: list of valid IP addresses for the token, i.e., those authenticated;
- Token Hash: SHA-256 hash signature, used to validate token authenticity.
Authgroup configuration allows defining a user pool from another Authgroup, enabling reuse or sharing of registered users across multiple authentication groups.
For authentication methods implementing 2FA before the login form, the system provides a customizable flow with screens adaptable to the protected application's visual style.
SMTP email sending can be configured, supporting "clear text", "TLS", and "SSL" methods, with or without authentication, for sending TOTP registration instructions and OTP via email.
Sender email address, subject, and message body can be parameterized for sending TOTP registration instructions and OTP via email.
The solution allows provisioning one or more Bastion modules per organization, acting as reverse proxies for protected applications, intercepting requests and implementing protection layers.
Protected URLs
The solution supports automatic SSL certificate generation for protected URLs using Let's Encrypt, with automatic renewal. Manual SSL certificate insertion is also supported if the administrator prefers not to use Let's Encrypt.
HTTP to HTTPS port redirection can be configured, ensuring all requests are secure.
SSL parameters and ciphers can be set via the web administration console for protected URLs, allowing additional security configuration.
Multiple backends (application servers) can be configured per protected URL, enabling load balancing.
The host name for accessing the protected URL can be customized, allowing access via a specific domain name for proper reverse proxy operation.
TOTP Authentication via App
According to RFC 6238, TOTP via app authentication requires the user to have an authenticator app installed on their mobile device, where the cryptographic key provided by the system must be registered. GuardianKey Auth Bastion allows QR Code generation for key registration, readable by authenticator apps.
The system implements user identification, TOTP code validation, and QR Code generation for user registration in the authenticator app.
User validation methods for QR Code display include:
- Email - instructions sent to the user's email with a link to generate the QR Code;
- Credentials - user validation via credentials (username and password) through integration endpoint;
- API - user registration and QR Code generation via API;
- Custom (Bastion) - user validation via custom LUA code.
The QR Code screen is not shown after the user has used TOTP via app for the first time, preventing QR Code reuse.
A start date can be set to require mandatory TOTP via app usage. Before this date, users can postpone usage by clicking an appropriate button. This feature reduces user friction and adoption difficulties.
The authentication policy (Authgroup) configuration allows setting the "TOTP issuer name," which identifies the TOTP source in the user's authenticator app.
Permitted email domains can be specified for sending TOTP registration instructions, restricting registration to users with emails from specific domains, e.g., only institutional email users.
OTP Authentication via Email and Integration
For sending the second authentication factor via email, permitted domains can be specified, restricting sending to users with emails from specific domains, e.g., only institutional email users.
OTP codes can be sent via POST to a configurable HTTP/REST endpoint, usable for other channels such as Telegram, SMS, etc.
OAuth2/OIDC Authentication
The system supports OAuth2/OIDC authentication in protected systems, such as GovBR. Integration parameters like Client ID, Client Secret, and authorization endpoints must be provided.
OAuth2/OIDC is implemented by injecting customizable JavaScript code into the protected system's login page. This code adjusts the screen to display the "Login with OAuth2" button with the authorization URL generated by GuardianKey Auth Bastion. The JavaScript can also remove the original login form and button if needed. Thus, protected system changes are made without modifying its source code.
After OAuth2/OIDC authentication, the authenticator redirects to GuardianKey Auth Bastion's callback URL, which submits information to the integration endpoint, creating the authenticated user's session directly in the protected system. This integration code is parameterized depending on the protected system.
User session cookies are sent, and the authenticated user is redirected to the protected system's screen.
Geolocation Firewalling
Firewalling by geolocation can be configured to block access from predefined countries.
This feature is configured per Authgroup and can be disabled, enabled in "Whitelist" mode (list of allowed countries), or "Blacklist" mode (list of blocked countries). In the latter two modes, specific countries can be allowed or blocked.
Integration Endpoints
API HTTP/REST integrations can be configured for endpoints to:
Retrieve user email information for sending TOTP registration instructions or OTP via email.
Send OTP for implementations that allow code delivery via other channels, such as Telegram, SMS, etc.
Validate user authentication, usable for user validation and QR Code generation for TOTP via app.
Identify user authentication settings for OAuth2/OIDC, allowing, for example, requiring OAuth2/OIDC authentication only for specific users.
Administration Console and Event Visualization
GuardianKey provides a responsive web console for policy administration and event visualization.
The administration and event visualization console is web-based, responsive, and requires no additional software installation. Compatible with major browsers (Chrome, Edge, Firefox, Opera, Safari, etc.).
The web console is available exclusively via HTTPS.
The console features dashboards for events.
Dashboards can be filtered by time or authentication group.
The console allows searching for events or users using filters and viewing event details.
Technical Requirements
Requirements for Bastion Module
For proper operation of GuardianKey Auth Bastion Enterprise, at least one dedicated server is required to host the Bastion module, which can be a virtual machine (VM), with the following configurations, depending on the number of users and requests:
Up to 100,000 users and up to 1,000 requests per second:
- 8 CPU cores
- 32GB RAM
- 100GB SSD storage and/or latency below 3ms for writing and at least 1,000 IOPS
- Internet connectivity
- Public routable IP for external access, if needed.
Above these limits, a processing cluster is required. Contact our business area.
Requirements for Controller and Administration Console Module
For proper operation of GuardianKey Auth Bastion Enterprise, at least one dedicated server is required to host the Controller and Administration Console modules, which can be a virtual machine (VM), with the following configurations, depending on the number of users:
Up to 100,000 users and up to 1,000 events per second:
- 12 CPU cores
- 128GB RAM
- 250GB SSD storage and/or latency below 3ms for writing and at least 1,000 IOPS
- Internet connectivity
- Public routable IP for external access, if needed.
Above these limits, a processing cluster is required. Contact our business area.