Hey everyone! 👋 After a few weeks of tinkering and testing, I finally got SAML authentication working smoothly between our FortiSASE setup and Okta for both the client portal and the admin portal. It was a bit of a journey, but the single sign-on experience is now seamless for our team, and the security posture is much tighter. I wanted to share the step-by-step process I followed, including a couple of gotchas that cost me some time, in hopes it saves someone else a headache.
First, let's talk about the core concepts. FortiSASE essentially has two main access points you'll want to secure: the **Admin Portal** (for us, the IT and security team) and the **Client Portal** (for our end-users to access protected resources). Configuring SAML for both follows a similar pattern but in separate sections of the FortiSASE dashboard. You'll be doing a dance between Okta and FortiSASE, exchanging metadata and attributes.
Here’s the high-level workflow I used:
* **In Okta:**
* Create two new applications (one for Admin access, one for Client access). I used the "SAML 2.0" template.
* Configure the General Settings, SAML Signing, and the crucial SAML attributes.
* Note the **Identity Provider metadata** (the URL) and the **Audience URI** (SP Entity ID) that Okta provides.
* **In FortiSASE:**
* For the **Admin Portal**: Navigate to **System** > **Administrators** > **Single Sign-On**. Here, you'll paste the Okta metadata URL and map the Okta user attributes to FortiSASE admin roles. The key attribute is usually `email` or `sAMAccountName`.
* For the **Client Portal**: Navigate to **Tenant** > **Single Sign-On**. The setup is similar, but here you're defining which Okta user groups or attributes grant access to the client portal and what level of access they have.
* FortiSASE will generate its own **Service Provider metadata** for each portal. You'll need to feed this back into the corresponding Okta application settings.
The tricky parts that tripped me up:
1. **Attribute Mapping is Key:** FortiSASE is particular about which SAML attribute it uses for username mapping. In our case, for the Admin Portal, we had to use `user.email` from Okta and ensure it exactly matched the admin username we had provisioned in FortiSASE. For the Client Portal, we mapped the `user.group` attribute to control access policies.
2. **Dual Configuration:** Remember you are setting up two *distinct* SAML trusts. Don't mix the metadata! I labeled my Okta applications clearly: "FortiSASE-Admin" and "FortiSASE-Client."
3. **Certificate Rollover:** Keep an eye on the SAML signing certificate validity in Okta. Set a calendar reminder before it expires to update it in both FortiSASE SSO configurations, or use Okta's auto-rollover feature if available.
The result? Our team can now log into our company Okta dashboard and launch either portal without another password prompt. It’s a huge win for user experience and operational security. The integration feels robust, and once you understand the two configuration paths, it's quite logical.
If anyone is going through this process, feel free to ask questions below! I'm especially curious if others have used different attributes for role mapping or have automated any part of the user provisioning flow.
—ec
Test, measure, repeat
That's awesome you got this working! The way you break it down into two separate applications for admin and client portals makes a lot of sense. I'm still new to this whole SAML world.
When you created the two apps in Okta, did you find you had to use completely different settings for each one, or were they pretty much the same setup just duplicated? Asking because I'd worry about mixing up the permissions later on.
Great question about the Okta app settings. You're right that the basic SAML configuration is nearly identical for both apps - the protocol doesn't care if it's an admin or a client. The main differences are really about how you handle user assignment and attributes.
For my setup, I duplicated the core SAML settings between the two Okta apps. The crucial part is making sure the assertion consumer service (ACS) URL and entity ID you configure in Okta point to the correct portal endpoints in FortiSASE. Where they truly diverge is in the attribute mapping.
* For the admin portal app in Okta, I mapped a user's `department` attribute (like "IT" or "Security") and assigned the app only to those specific groups.
* For the client portal app, I mapped a broader `username` attribute and assigned it to a much larger user group.
This separation in Okta's group assignments became my single source of truth for permissions, which actually simplified management later. Did you run into any specific hurdles with the attribute mapping part?
automate everything
Great point about worrying over mixed permissions. I totally get that. The key difference, like user1307 said, is in the user assignment, not the core SAML config.
What helped me avoid mix-ups was using a super clear naming convention in Okta right from the start. Instead of just "FortiSASE - Admin," I named mine `fortisase-prod-admin` and `fortisase-prod-client`. Adding that environment tag `-prod-` made it impossible to confuse later.
Also, the group assignments act as your built-in safeguard. Your admin portal app should only have, say, your IT_Security group, while the client app gets a broader set. If someone tries to log into the wrong portal, the SAML assertion just won't have the right group membership, and they'll get bounced. That separation gives me a lot of peace of mind.
Data > opinions
Exactly. Nailing the attribute mapping is what makes the whole thing click. For the client portal, I found mapping `sAMAccountName` (for our AD) worked better than a plain `username` attribute. Okta passed it through perfectly, and FortiSASE accepted it without any extra config.
What really tripped me up at first was the NameID format. Had to set it to "Unspecified" in Okta for our setup, otherwise the assertion would fail. Spent an hour on that little detail!
dk
Ah, the "Unspecified" NameID format. That's often a red flag for a misconfigured SAML SP on the service provider side, not a best practice. FortiSASE should be able to declare what format it expects.
While your workaround gets it working, I'd be curious if it's masking a version mismatch or a configuration drift. Have you checked if the vendor has updated their SAML metadata or if there's a known bug in your FortiSASE firmware? Relying on "Unspecified" can bite you during an upgrade when the vendor finally tightens their schema validation.
cost_observer_42
The sAMAccountName tip is a good one. For AD-backed setups, it's usually more reliable than a custom username attribute.
I'm with user482 on the "Unspecified" NameID. It got things working for you, which is the immediate win. But I'd check the ROI on that setting versus using the proper format FortiSASE expects in its SP metadata. A future update could break it and you'd be back in the logs for that hour.
Ask me about hidden egress costs.
I agree that `sAMAccountName` offers better reliability for AD integrations, as it's a defined, system-level attribute. However, its use depends on your provisioning workflow. If you're syncing users from AD into Okta via SCIM and then using Okta as the authoritative source, mapping a custom "Username" field that's been populated by the sync can sometimes be cleaner. This abstracts you from the underlying AD schema, which is helpful if that ever changes.
On the NameID format, while "Unspecified" is indeed a workaround, diagnosing the root cause requires checking the Service Provider's requested format in its SAML metadata. Often, the IdP (Okta) and SP (FortiSASE) metadata have a format mismatch. The proper fix is to align them, but using "Unspecified" can be a valid, stable configuration if the SP's metadata is incorrectly declaring its requirement or is overly permissive by design. It's less about a future update breaking it and more about understanding if the SP's lax validation is a permanent feature or a bug.
You could validate this by examining the AuthnRequest from FortiSASE in your browser's SAML tracer or by downloading its metadata file to see the exact `NameIDFormat` elements.
You're spot on about the provisioning workflow dictating the attribute choice. I went the SCIM sync route, and using a custom field from Okta as the username did simplify things when we did an AD migration last year. No need to touch the SAML config at all.
For the NameID mismatch, I've found that SP metadata often doesn't get updated when vendors push patches. So `Unspecified` isn't always a hack, it can be a practical long-term stance if the vendor's metadata is static and known to accept it. The real risk is when you onboard a *new* SP that's stricter, and you've built a habit of using the workaround.
— francesc