Mastering Identity-Based Firewall Policies for Modern Network Security

If, like me, you’ve been around networking since the early ’90s — started off babysitting those clunky PSTN muxes, watched the infamous Slammer worm spread across the Internet and generally took out more mainstream services than Friendster — you know that securing networks is part art, part eternal hustle. Flash forward couple 3 decades and a lot of grey hair later, and I’m still boots-on-the-ground active but now running PJ Networks and helping businesses (especially banks) step-up their zero-trust game. And while I’m getting back on my plane to the mainland from DefCon’s hardware hacking village (this will probably never stop, given how much I’m still buzzing), here’s something that ticks me off: identity-based firewall policies.

Policy Models

Indeed, as everyone in the industry is trying to figure out how to secure corporate traffic from home-bound employees, the limitations of existing models are becoming apparent: Firewall rules in the data center have been traditionally IP-centric — and this was just fine when employees sat at desks all day, typing millions of words at their desktop machines with mostly-static IP addresses. But today? IPs are like that bar of soap and slippery. Mobile phones, remote work, cloud-based apps — you name it. So, yeah, here’s the thing: If your firewall rules don’t know who the user is, they’re really a little trigger-happy in the dark. To see why firewall policies based on identity are so transformative, think of it like this: where traditional access control is based on IP – the network layer – identity-based firewall policies turn that on its head.

This is where Fortinet’s FortiAuthenticator comes in and changes the game completely. It dynamically maps the user to the session, thereby associating it with the user, mapping it back to the fw rules based on user identity via AAA mechanisms. Would you like access to internal resources behind that firewall, using your existing identity provider; yes, this is a bit of a tango – Identity provider, firewall rule, accessing the access-point – but, PJ Networks has policy templates to make this far less painful.

• Policies can be granular.
• Role, department, even time of day-based allow/block Cookie policy: You can decide whether to allow or block Cookies.
• Enforcement remains accurate, whether the end user is on Wi-Fi or VPN.

But beware. I’m suspicious of any AI-powered firewall that says it can magically do this, no configurations necessary. Yes, identity based configuration is contextual, and it’s not a black box magic trick.

Identity Integration

A: Integrating identity is fancy talk for plumbing into your directory services (Active Directory, LDAP and the like)., and synchronizing those user attributes with FortiAuthenticator. Now, don’t miss this step, because this is often where the process falls apart or gets flaky. PJ Networks experience (and yes we have been there hundreds of times) has shown that successful integration requires:

• Full discovery of current identity stores.
• Synchronize It can schedule which isn’t falling behind the user’s changes.
• Transparent correlation of user-groups with firewall policies.

Frequently, the shortcuts that organizations want to take past this reconnaissance step is thinking, “if we just slap on FortiAuthenticator, we’re done.” Nope. Not even close. You must make certain that users are enrolled, authenticated, and that your system is capable of correlating their identities across endpoints and access points on the fly.

Pro tip: Absolutely opt into multi-factor authentication here. Nothing like a good blindsiding via compromised creds to remind you why MFA ain’t optional.

AP Contextual Data

What makes this possible, is the AP context. Identity is one aspect of the picture, but the Fortinet ecosystem enables you to draw contextual information from wireless APs—such as device type, location and even connection history.

It is just that PI networks are always keen on layering these dimensions. Why? A user logging in from the CEO’s laptop in a locked room with only a security guard as the witness, is a LOT different from the same creds on an abusive belligerent from random device at a coffee shop. AP context data provides policy with situational awareness, allowing firewall policies to evolve and adapt.

Here’s a quick example:

• User: Marketing associate.
• Location: Corporate HQ, tethered to corporate Wi-Fi.
• Device: Corporate laptop.

Firewall policy: All Access as per marketing role.

Contrast with:

• Same user, non-office, other device.

Firewall policy: Limit access and extra scrutiny.

You see where this is going.

Implementation Guide

Alright—now the nitty gritty. Making FortiAuthenticator, FortiGate firewalls, and APs all get along together in service of a policy-based identity world?

1. Set up FortiAuthenticator: Work with your identity sources. Configure sync with AD/LDAP. The check is that user groups are correctly imported.
2. Set up FortiGate: Generate user-based firewall policies that use the synced user groups.
3. Combining APs: Configure APs to pass client authentication information to FortiGate/FortiAuthenticator. This is where you introduce the context.
4. Map Policies: Create policies based on user role, device and location using PJ Networks branded templates.
5. Turn on Logging/UAT: PJ Networks isn’t set and forget. We keep watch on 24×7 monitoring SOC level validation and look for any discrepancies or signs of compromise.

Remember: Firewalls are only as strong as how well you maintain and monitor them. You let your policy sets get caught in a spaghetti mess, and it’s like running an old, uncalibrated carburetor on a Formula 1 car—your performance goes into the tank and you keep wondering why the engine stalls on you.

PJ Networks Expertise

And if there’s one thing we’ve learned over the years it’s that identity-based firewall policy endeavors are not just technical jobs—they’re personal, experienced, and deeply understood client workflow opportunities. Most recently, we assisted three large banks in updating their zero-trust architecture leveraging the Fortinet stack. This meant:

• Writing policy templates that are tailored for regulatory maintenance, without strangling user performance.
• UAT with real users, not just the IT guys (trust me, they test differently).
• Offering 24×7 SOC validation and dynamic tuning—because the real world is messy and user behavior evolves.

There’s not some cookie-cutter solution here. Customized mappings and rolling policy modifications are needed for each environment.

And yes, I’ve made my mistakes over the years, rolling out policies that inadvertently blocked legit users or left gaping holes in cyberspace. But that’s how you learn.

Testing & Validation

Testing is not an afterthought. It’s mission critical. Identity-dependent firewall policies are hampered by… moving parts: evolving user roles, device churn, variable AP coverage.

At PJ Networks, we live the above: start with pilot groups and refine policies. Schedule regular rollout for a real user scenario. That means testing real workflows during business hours; make sure the users test from different devices and access points, remote versus office. Cover 24×7 SOC monitoring of logs, user behaviors, authentications, and schedule tuning.

A small rant on passwords, I know it is 2021 Let me tell you about identity integration. It doesn’t work if weak passwords or shared logins are prevalent. Strong password policies and continuous education. None of the identity-based firewall policies that FortiGate up above work a lot without them.

Take-Away

Because security relies less and is influenced, confirmation of your policies will assume a role. Another significant win: PJ Networks have reliable templates for proven 17-year templates. Book your 24-7 validation with us and breeze through that checklist.

Validation. The future of firewall policies is identity-aware. It is over. I cannot express enough that if your current firewall policies are still only intended to use the IP address, you are lacking the trend.

Finally, it is a drive. To all who have read so far – thank you. With my fourth coffee in tow, I hope this post has sparked a concept or two – and perhaps a dispute. Identity-based firewall rules? Not all propaganda.