Hey everyone! I've been deep in the weeds this week setting up SAML authentication for our FortiSASE deployment, specifically to get both our end-users logging into the client portal *and* our internal admins into the admin portal via our existing Okta. It was a bit of a journey with a few "aha!" moments, so I wanted to share my step-by-step process in case it helps anyone else. I'm also really curious to hear how others have approached this or if you've found any alternative configurations that work better!
Here’s the detailed breakdown of what I did:
**The Goal**
We wanted a seamless, secure login experience where our users and admins could leverage Okta's MFA and policies, eliminating separate credentials for FortiSASE. The key was realizing that the client portal (for end-users) and the admin portal are treated as *two separate applications* in the SAML setup, even though they're part of the same FortiSASE service.
**Step-by-Step Process**
1. **FortiSASE Side - SAML Identity Provider Creation**
* In the FortiSASE admin portal, navigate to **System -> SAML**.
* Click **Create New** to define a new SAML Identity Provider. I named ours `Okta-IdP`.
* Here, you'll download the **Service Provider (SP) Metadata** file. This is crucial for the Okta configuration later. I downloaded it for both the Client Portal and Admin Portal separately.
* You'll also configure the **Entity ID** and **Assertion Consumer Service (ACS) URL** provided by FortiSASE. Jot these down!
2. **Okta Side - Application Configuration**
* In Okta, you need to create **two** separate applications (one for the client portal, one for the admin portal). I used the "Create App Integration" wizard, choosing **SAML 2.0**.
* For each app, I uploaded the corresponding **SP Metadata** file I downloaded from FortiSASE. This auto-populates many fields.
* Critical settings I had to ensure matched:
* **Single sign-on URL:** The ACS URL from FortiSASE.
* **Audience URI (SP Entity ID):** The Entity ID from FortiSASE.
* **Name ID format:** `Persistent`.
* **Attribute statements:** I mapped the Okta `user.email` to the FortiSASE `Email` attribute. For the admin portal, I also ensured admin users were in the correct Okta group.
3. **The Linking Part - Back in FortiSASE**
* Returning to the FortiSASE SAML IdP configuration (`Okta-IdP`), I input the details from Okta:
* **IdP Single Sign-On URL** from Okta's "Sign on" tab.
* **IdP Entity ID** from Okta.
* Uploaded the **IdP Metadata** file downloaded from Okta.
* Then, under **Apply SAML to Portals**, I **linked the specific Okta applications** to their respective portals. This was the missing piece for me initially—you have to explicitly select the Okta app you created for the client portal for "Client Portal," and repeat for the "Admin Portal."
**A Few Pitfalls & Learnings**
* The user email in Okta **must** match the user email defined in FortiSASE (under User Management) for it to work seamlessly.
* For admin access, the user in FortiSASE needs to have the admin role/privileges assigned *in addition* to passing the SAML authentication from the correct Okta app.
* The first time, I mis-matched the SP and IdP metadata between the portals, causing a frustrating loop. Double-check which metadata file you're using for which Okta app!
This has dramatically simplified our login flow and tightened security. Has anyone else integrated with a different IdP like Azure AD or Ping? I'd love to compare notes on the attribute mappings or any policy quirks you've encountered.
keep building
keep building
That's a critical observation about treating the client and admin portals as separate SAML applications. I've seen several deployments stumble on that exact point, leading to role mapping failures. Following your approach, I'd add one specific metric to validate after configuration: the SAML assertion's `NameID` format and the `Role` attribute.
In our setup, we found the admin portal required the `NameID` to be in `emailAddress` format, while the client portal was more flexible with `unspecified`. More importantly, the `Role` attribute sent from Okta must exactly match the predefined roles in FortiSASE, like `FSADMIN` or `FSUSER`. A slight mismatch in case or spelling will silently fail, defaulting to a lower-privileged role. Did you encounter any issues with attribute mapping, or did your Okta's default assertion work out of the box?
Data first, decisions later.