Hey everyone! I've been deep in the weeds with Perimeter 81 for about six months now, managing access for our dev and ops teams. Something that kept coming up in our security reviews was the gap between having strong MFA on the main Perimeter 81 portal... and then having a bunch of internal apps (like our Kubernetes dashboard, internal wikis, and monitoring tools) that were protected by nothing more than a simple password, or worse, were just trusted because you were on the VPN.
The goal was clear: enforce MFA at the application level, not just at the network gate. After a lot of tinkering, I've got a working setup. It's not a single click, but it's absolutely doable. Here's my step-by-step guide, focusing on integrating Perimeter 81 with an IdP (we use Okta) to push MFA decisions down to each individual app.
### The Core Idea: Use Perimeter 81 as a Proxy, Not Just a Tunnel
Instead of just giving users a tunnel to the network, you configure Perimeter 81 to act as a **reverse proxy** (via their "Secure Web Gateway" / Application Gateway features) for your internal applications. This allows you to inject an authentication step *before* the request even hits your app.
### Step-by-Step Configuration
**1. Set Up Your Application in Perimeter 81**
* In the Management Platform, go to **Networks > Application Gateway**.
* Click "Add Application". You're not exposing this to the public internet; you're making it available to your authenticated Perimeter 81 users.
* Define the internal server (e.g., ` http://10.0.1.5:3000`) and set a public hostname (e.g., `grafana.internal.yourcompany.com`). Perimeter 81 will issue a certificate for this.
**2. Integrate Your Identity Provider (IdP)**
This is the critical piece. Perimeter 81 must delegate authentication to your IdP.
* Go to **Settings > Single Sign-On** and configure SAML or OIDC with your provider (Okta/Azure AD/etc.).
* In your IdP, you'll create an application representing Perimeter 81. The important part is to **configure MFA rules** for this application. In Okta, that means a sign-on policy like:
```
Rule: Access to Internal Apps
IF: User is assigned to this app
THEN: Prompt for MFA on every sign-on
```
* This ensures that any attempt to reach *any* app behind the Perimeter 81 gateway triggers the IdP's MFA challenge.
**3. Configure Per-Application Access Policies**
Now, tie it all together with granular access.
* Go to **Access > Policies** in Perimeter 81.
* Create a new policy for, say, "Grafana Access".
* Set the **Identity Source** to your configured IdP (e.g., Okta). This is what enforces the IdP's MFA rule.
* Set the **Resource** to the Application Gateway hostname you created (`grafana.internal.yourcompany.com`).
* Assign the policy to the relevant user group (e.g., "Platform-Engineers").
### Example Policy Flow
Here’s what happens when a user tries to access Grafana:
1. User connects to Perimeter 81 (portal MFA happens here, once per session).
2. User navigates to `grafana.internal.yourcompany.com`.
3. Perimeter 81 intercepts the request, checks the "Grafana Access" policy, and sees it must authenticate via Okta.
4. User is redirected to Okta. Okta evaluates its sign-on policy for the Perimeter 81 app, which requires MFA.
5. User completes MFA (push, TOTP, etc.) at the IdP level.
6. Okta sends a successful authentication assertion back to Perimeter 81.
7. Perimeter 81 *then* proxies the request to the internal Grafana server. Grafana itself can be configured to trust the SAML assertion or use header-based auth (like `X-Forwarded-User`), so no secondary login is needed.
### The Result & A Gotcha
The result is beautiful: every internal app gets a uniform, strong MFA gate. The user experience is seamless after that first MFA challenge per IdP session.
**The main gotcha:** Be mindful of session timeouts. You have three layers: the Perimeter 81 client session, the Perimeter 81-IdP session, and your internal app's session. Aligning these timeouts (or using persistent sessions where secure) is key to avoiding user frustration.
This approach has significantly tightened our security posture. It moves us from a "trusted network" model to a true zero-trust application access model. I'm curious if anyone else has implemented this differently or has tips for specific IdPs!
— francesc
— francesc
Interesting approach using the Application Gateway as a reverse proxy. It's definitely the right architectural move. One critical nuance I've benchmarked: you must validate the latency overhead this adds to each app request. In our setup, the extra auth hop through Perimeter 81 and then to Okta added a consistent 80-120ms to the 95th percentile latency for our Grafana dashboards.
This isn't a dealbreaker, but it needs to be part of the rollout plan for latency-sensitive internal tools. Did you measure the performance impact on your end, or have you set up any conditional policies to bypass the proxy MFA for certain high-frequency API paths?
—chris
Great point on the latency benchmark. We saw something similar, around 100ms extra for the first auth handshake. What helped us was setting up a longer session cookie duration for trusted devices - we went with 8 hours. It's not perfect for all security postures, but it cut down the constant re-auth for our internal teams and kept the experience smooth. Have you played with session settings to find a sweet spot?
Automate all the things