How it works
Components
The solution has three parts.
| Component | Where it runs | What it does |
|---|---|---|
| Portal | Published to users, on the same outbound network as the protected system | Login with password and authenticator code, authenticator enrollment and creation of unlocks |
| Decision service | Inside Bastion Pass | Answers, on each connection, whether access may go on. Stores the unlocks in its own database |
| Integration module | Next to the protected system | Reports each new connection to the decision service and closes the ones that are denied |
Bastion Pass is the only component that talks to the company directory (Active Directory or another LDAP), to Auth Bastion and to Auth Security. The integration module talks only to Bastion Pass, over an authenticated channel accepted only from authorized servers.
The portal and the protected system sit side by side so that the IP seen by the portal is the same IP the system sees when the user connects.
Portal login
When the user signs in to the portal, Bastion Pass runs these checks, in this order:
- Form protection with GKTinc: the browser solves a proof-of-work challenge, harder for IPs with a bad reputation. Bots and brute-force attempts stop here.
- The user's password, checked against the company directory.
- Login risk analysis in Auth Security. A login classified as a block is denied.
- Auth Bastion IP and user policies. Blocked users and networks are denied. Exempt users and networks are told they do not need an unlock.
- The authenticator app code. On first access, the portal shows the enrollment QR code and asks for the first code.
- Creation of the unlock for the user and source IP.
Once the authenticator is enrolled, the portal does not generate a new QR code. To switch phones, the user asks the administrator, who resets it in the Auth Bastion panel.
Check on every connection
On each new connection to the protected system, the integration module sends the user and source IP to Bastion Pass. The decision follows this flow:
Exempt users and networks also go through risk analysis. In that case the result is recorded and raises an alert, but does not block the connection.
Unlock validity
| Portal option | Default validity |
|---|---|
| "Trust this IP" checked | 30 days |
| "Trust this IP" unchecked | 12 hours, renewed on each accepted connection, up to 24 hours from creation |
The periods are set in the Bastion Pass configuration. When an unlock expires, the next connection is closed and the user goes through the portal again.
Administration and audit
Bastion Pass has no administration screen. The administrator uses the Auth Bastion panel to:
- exempt or block users and networks, through user and IP policies;
- reset a user's authenticator;
- follow risk events in Auth Security.
Every Bastion Pass decision, in the portal or on a connection, is written to an audit trail with user, IP, origin, result and reason. Situations that need the operations team's attention, such as an external API not responding or a connection that could not be closed, raise an alert in the log.
Customization
The portal takes the customer's visual identity without code changes: product name, logo, icon, colors and support link.
Availability
Bastion Pass instances keep no state. All state lives in the database. You can therefore run several instances behind a load balancer and use a replicated database. The integration module accepts a primary and a secondary Bastion Pass.