IdP Integration and SSO Federation: A Practical Guide with FortiAuthenticator

Sipping my third cup of coffee as I’m writing here at my desk (I’m a caffeine junkie, okay, I admit it), I’m also reflecting on the early days of my career, when I began as a network admin back in 1993. Oh boy, weren’t those the days. It seemed like taming wild stallions in comparison to what we deal with in cyber defenses today, just establishing mux for voice and data over PSTN. And then there was the Slammer worm — ah, let me tell you, that curveball was a lesson in the fragility of our networks.

Now I run my own cybersecurity company and I roll up my sleeves and get into more modern types of challenges — like guiding three banks to upgrade their zero-trust architecture recently. Federated identity management is a large part of that puzzle. Oh, and having just returned from DefCon (with the hardware hacking village infectiousness still coursing through my veins), I thought I’d spin up some thoughts of how to connect FortiAuthenticator with 3rd-party identity providers (Okta, Azure AD, Ping) for federated SSO.

IdP Background: Why Use 3rd Party Identity Providers?

First off, let me clear this up – federated SSO is not a panacea. But here’s the problem: when you’re juggling a sprawling enterprise network (or banks, for that matter) managing a half-dozen user databases and authentication sources is like trying to keep track of every spice in a large kitchen—messy and inefficient.

Identity Providers (IdPs) are the central user management sources (Okta, Azure AD, Ping, etc.). They take care of authentication and forward the verified user’s identity to your systems—in our case, FortiAuthenticator—as your users should not need to keep a dozen logins in memory or wrangle a hokey-pokey token of a VPN.

Why FortiAuthenticator? It’s Fortinet’s powerful platform to ease authentication, especially in zero trust configurations. It is integrated with your IdP for federated SSO. This way your network security lines up with your cloud identity strategy.

Quick reality check: Some people in cybersecurity believe that identifying everyone should not turn into an Rube Goldberg machine of components too complicated for anyone but a trained expert to fit together. And I get it. However, I know from firsthand experience, and especially in the world of banking, that a properly administered federated SSO is in a different league to standalone solutions.

SAML/OIDC – Getting Your Hands Dirty

There are two main protocols you deal with; SAML (Security Assertion Markup Language) and OIDC (OpenID Connect). Both aim for the same endgame: authenticating a user without storing their credentials on your local site. But it’s as though, compared with different dialects of the same language.

For enterprise-level stuff, I still favor SAML — more chatty, established, enterprise-ey. OIDC is slimmer and up to date, excellent for mobile apps or newer cloud services.

A simplified method we use at KPJ Networks for combining FortiAuthenticator with IdPs: Let’s Get Technical (As briefly as possible!) Here’s a simple way that we do for enabling FortiAuthenticator for IdPs at KPJ Networks:

1. Prepare your IdP –
   • New App/Entity registration of FortiAuthenticator
   • Specify the redirect URIs and assertion consumer service URLs accurately
   • Export the IdP metadata (commonly XML for SAML or JSON for OIDC)
2. FortiAuthenticator Configuration –
   • Import the IdP metadata
   • Configure Identity Provider parameters and SSO URLs
   • Set the authentication types (2FA, OTP, and so on)
3. Establish trust –
   • Add the signing certificates
   • Allow secure assertions if possible
4. Enable the federation –
   • Activate SAML/OIDC authentication method for your user groups
   • Set up a contingency authentication for emergency access (trust me, you’ll appreciate my pro tips)

And never forget the oddities in metadata interoperability. (Okta and Azure AD both refer to things differently, or they expect extra attributes, or something else that makes you feel like you’re translating ancient texts.)

Attribute Mapping: The Magic Happens Here

This is where a lot of admins mess up — or at least get grumpy. To match up a list of attributes is rather like making a recipe. Your IdP sends you data for a user (attributes), FortiAuthenticator needs to know what an attribute means, in order to apply a policy correctly.

Some common features we work with:

• Username (usually userPrincipalName or email)
• Groups (role-based access control is dependent on this.)
• E-mail (for notification or auditing)
• User ID (uniquely identifying – often objectGUID or sub in OIDC)

At PJ Networks, my staff and I have learned to never assume that defaults are correct (you can also see the attribute names your IdP sends by enabling debug logs). You’re essentially after the kitchen labels that come with each ingredient to guarantee your recipe comes out right.

And here’s a pro-tip:

• Map groups to FortiAuthenticator user groups to provide access as needed
• Use attributes to dynamically apply MFA policies (e.g: OTP is mandatory for a set of groups)
• Standardize attribute formats — Some IdP’s email all upper, some all lower, non-standardization kills automation.

I spent half a day tracking down a bank’s SSO failure once because the IdP was sending group names with trailing spaces. Yeah, spaces. Don’t laugh—it happens!

Testing & Validation: Please Don’t Skip This Step

You can’t just check Testing federated SSO. It would be like fine-tuning your car engine before a cross-country road trip. When you forego the necessary validation, your users are left out in the cold, tickets swamp your helpdesk and your reputation disappears quicker than your third coffee at the office.

We employ multi-stage testing scheme as follows:

• Connectivity – check handshake between FortiAuthenticator and IdP is matching with your email/domain.
• Login flow – Test the login between user portal and app and see if it gets redirected & token exchanged
• Attribute validation – Validate on correct attributes are map following login
• Role compliance – Groups based policies are enforced as expected
• Back up options – Test an alternate access in case IdP is not available

And here’s my somewhat controversial opinion: most companies are too busy doing functional testing and not at all worried about what could really go wrong. So what do you do if your IdP misbehaves? Network glitches? Expired certificates? Nobody pays any attention to that until they get bitten.

At PJ Networks, we emulate these failures. And we design resiliency into the FortiAuthenticator deployment — it’s not perfect, but it’s certainly better than relying solely on blind faith.

Quick Take: In Case You’re Time-Strapped

• FortiAuthenticator + IdP integration = single sign-on to centralized resources to reduce password fatigue
• SAML for legacy enterprise setups (OIDC for cloud/mobile)
• Never take attribute mappings for granted—test everything
• Hard testing versus Smart testing: normal use and failure modes
• Dynamically apply policies using mapped parameters for better zero-trust stance

Final Thoughts From a Guy Who’s Seen Too Much

When I reminisce about those network admin days — juggling mux lines, fighting with dial-up, then weathering Slammer — I realize something: The excavation tools might be different, but the stakes are the same. Identity is everything now. Terrible integration means you might as well have a gaping hole in your security perimeter.

Here’s a bit of a rant to wind down with: I’m absolutely fucking sick of hearing just add a password policy policy as if it’s some magical solution. Just passwords are dead weight (Though your users are doing their bit to keep recycling them, so don’t laugh). Federated SSO with FortiAuthenticator and your IdP is like stepping out of a manual old-timer and into an automatic—less effort, more control, and fewer crashes.

I get it — there are no ideal fixes. But done right, this integration pays dividends in user experience and security. And for those of you pondering AI-fueled identity solutions, please know that humans design those systems — and humans err. You can’t outsource your security thinking to a black box that’s going to solve all your problems.

Given that, if your organization is still handling identities like it’s 1995 — trust me, it’s time for an update. Begin with FortiAuthenticator and federate with your IdP. Your networks — and your users — will appreciate it.

Okay, four coffee, off we go. See you next time, and keep your firewalls tight and your authentication tighter.

— Sanjay Seth, PJ Networks Pvt Ltd