How authentik signs administrators in to Cisco FMC over SAML
The supported method for signing firewall administrators in to Cisco Secure Firewall Management Center through authentik is SAML single sign-on, as documented in the authentik integration guide for Cisco FMC. This section covers administrator access to the FMC web interface only. Users who connect through VPN are a separate population with their own authentication path, and the same SAML approach does not by itself define how they reach the network.
authentik supplies the identity side of the arrangement. You create a SAML provider and an application in authentik, which authenticates the administrator, applies your MFA stages and returns assertions that identify the user and their group membership to FMC. Those assertions are the only thing authentik contributes to the login. The guide's own configuration values, such as the entity IDs, assertion consumer URL and signing certificate, should be copied from the current integration page rather than from older notes, because the FMC side must match them exactly.
FMC still controls what an authenticated administrator can do. Its user roles, the mapping from SAML attributes or groups to those roles, and the local accounts it keeps are configured inside FMC. Confirm with your own FMC version how externally authenticated users are provisioned and which roles they receive, and decide before go-live who holds a local administrator account for break-glass access if authentik or the SAML path is unavailable. Testing that break-glass login is a precondition for production, not an afterthought.
What you need before configuring Cisco FMC SAML
Most failed SAML logins to Cisco Secure Firewall Management Center trace back to decisions made before the configuration starts. The items below connect authentik, FMC and your access model, so confirm each one before you touch either side.
Supported authentik version
Run authentik on a version that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported lines, and security releases are announced at least 24 hours in advance. Confirm your running version matches one of those lines before you build the SAML provider, and plan an upgrade path if you are behind. Check the release notes for any change to SAML provider fields that affects your setup.
FMC SAML support confirmed
Before you plan the work, confirm in Cisco's documentation for your exact FMC version that SAML single sign-on is supported and which settings it expects. Record the FMC software version, the SAML login options it exposes and any constraints on identity provider metadata. Do not rely on a configuration guide alone to establish version support.
DNS names and TLS certificates
Give FMC and authentik stable, resolvable DNS names with valid TLS certificates that clients trust. SAML assertions and redirects depend on those hostnames, so a name change later means updating entity IDs, assertion consumer URLs and metadata on both sides. Decide which certificate authority issues each name and who owns renewal before the cutover date.
Group structure matching FMC roles
Design the authentik groups before you configure role mapping. Each FMC role that an administrator can hold should correspond to one authentik group, and each group should have a clear owner. Document which users belong to which group and who approves changes, because the group membership in the SAML assertion is what grants access in FMC.
Out-of-band recovery admin
Keep at least one local FMC administrator account that does not depend on authentik. If the identity provider, its certificate or the SAML settings fail, that account is the only way back into the management interface without a rebuild. Store its credentials in your secrets process, test that it logs in, and confirm who may use it and how that use is logged.
Field names from the integration guide
Use the authentik integration guide for Cisco FMC as the source of exact field names, application settings and attribute names. Copy values from the guide and from your FMC screens rather than from memory, and keep a record of each value you set. Mismatched attribute names are a common cause of users logging in with the wrong role.
Configuring the authentik SAML provider and FMC SSO in sequence
This sequence connects authentik to Cisco Secure Firewall Management Center as a SAML identity provider, maps authentik groups to FMC roles, and adds MFA to the sign-in flow. The order matters because FMC needs authentik's metadata before it can trust sign-ins, and role mapping must be verified before administrators depend on it.
Create groups for each FMC role
An administrator in authentik creates one group per FMC role that will be used, such as a group for read-only analysts and a group for full administrators. Keep membership limited to the people who should hold that role, and add only a small set of test accounts to each group for the checks later. Record the exact group names, because the role mapping in FMC depends on them. The step is done when each group exists, lists its intended members, and the names are written down in a form that matches your change record.
Create the SAML provider and application in authentik
Using the authentik integration guide for Cisco FMC as the reference, the identity administrator creates a SAML provider and an application in authentik. Set the assertion consumer URL, entity ID and signing options exactly as FMC expects, then bind the application to the authorization flow that will be used for sign-in. Confirm the settings against the guide and your FMC version, since field names can change between releases. The step is done when the application appears in the authentik application list and the provider shows a valid metadata endpoint.
Export metadata and the signing certificate
From the authentik provider, the administrator downloads or copies the SAML metadata and the signing certificate. Store the certificate in a secure location with the change record, and confirm its validity period so that a future rotation is planned rather than discovered during an outage. If your authentik deployment uses a certificate that differs from the default, verify that the copy matches the one authentik is currently signing with. The step is done when the metadata file or URL and the certificate fingerprint have been captured and checked against the provider page.
Enter identity provider details in FMC SSO settings
A firewall administrator opens the single sign-on settings in Cisco Secure Firewall Management Center and enters the identity provider details from the authentik metadata, including the entity ID, sign-on URL and signing certificate. Keep a local administrator account active and documented before saving, so that recovery remains possible if SAML fails. Save the configuration and confirm that the SSO option appears on the FMC login page. The step is done when FMC accepts the settings without errors and the SSO login option is visible to test users.
Map attributes and groups to FMC roles
The administrator configures the attribute or group claim that authentik sends in the SAML assertion, then maps each authentik group to the matching FMC role. Confirm the claim name and value format in the assertion before writing the mapping, because a mismatch sends users into the wrong role or no role at all. Remove any default or overly broad mapping. The step is done when a sample assertion, captured from a test sign-in, shows the expected group values and each group maps to exactly one intended FMC role.
Enable MFA in the authentik authentication flow
The identity administrator adds an MFA stage to the authentication flow bound to the FMC application, using a second factor type that the organization has approved. Decide whether MFA applies to every user or only to the administrator groups, and check that the stage order places the password step before the second factor. Confirm that recovery and enrollment for second factors are documented for the help desk. The step is done when a test sign-in prompts for the second factor and the sign-in is recorded in the authentik event log.
Test with a non-admin user first
Before opening SSO to all administrators, a tester signs in to FMC with a non-admin test account from the group that carries the most restricted role. The tester confirms that the login completes, that MFA is requested, and that the account shows the expected FMC role and no additional privileges. Repeat the test for each role group. Review the authentik and FMC logs for any warnings about assertions or certificates. The step is done when each role group has produced a successful login with the expected role shown on the account.
Enable SSO for all administrators
Once every role has passed testing, the change owner widens access by adding the remaining administrators to the correct groups and confirms that the local emergency account still works. Announce the change to administrators, including the login steps and who to contact for MFA problems. Keep the test accounts and their logs for the change record. The step is done when all intended administrators can sign in through SAML, the local emergency account has been verified, and the change record includes the test results.
How groups and attributes map to FMC roles
Start by deciding which administrative roles your organization needs in Cisco Secure Firewall Management Center, then create one authentik group for each role rather than mapping individual users. Groups keep access reviews simple because membership changes in authentik flow through to FMC at the next login. Keep the group list short. Each extra group is another path to administrative access that someone must review.
- Role inventory: List the FMC roles your team uses today and the people who hold each one.
- One group per role: Create groups in authentik whose names match the role purpose, such as a read-only network group and a policy administrator group.
- Membership ownership: Name the person or team who approves changes to each group.
- No shared admin accounts: Map named administrators only, so audit logs show who made each change.
- Test users: Use a non-production administrator in each group to confirm the role they receive matches expectations.
Before go-live, confirm the role names and values with the Cisco FMC settings and the authentik integration guide in your own environment.
The SAML assertion from authentik tells FMC who the user is and which group or role attribute applies. FMC reads the attribute name and value you configure on its side, so both ends must agree on the exact spelling and case. A mismatch usually produces a login that succeeds but grants no role, or a denied login, which is why this step needs a deliberate test.
- Attribute name: Confirm the attribute name FMC expects for group or role data, as listed in the Cisco FMC settings.
- Attribute values: Use the role values FMC expects, and map each authentik group to exactly one value unless your FMC configuration supports multiple roles.
- Property mappings: Configure the authentik SAML provider to send the group attribute with the values FMC matches.
- Name identifier: Choose the user identifier format FMC uses so accounts are not duplicated on each login.
- Assertion check: Inspect a sample assertion from a test login to confirm the attribute appears with the expected values.
Compare every name and value against the authentik integration guide and the FMC configuration screens before you enable the mapping for all administrators.
Keep at least one local FMC administrator account that does not depend on authentik. If the identity provider, its certificate or the network path to it fails, SSO-only administrators lose access to the management interface and may be unable to fix the configuration. The local account is an operational safeguard and should be treated as a privileged credential.
- Separate credential: Store the local account password in your privileged secrets store, not in a shared document.
- Limited use: Restrict the account to break-glass situations and record each use.
- Login test: Verify the local login works after the SAML setup and after each major change.
- Alerting: Forward logs of local logins to your security monitoring so unexpected use is noticed.
- Review cycle: Confirm the account still exists and its password is current during regular access reviews.
Confirm with Cisco how FMC handles local accounts when external authentication is enabled in your version before you disable any existing administrator.
Role mapping can drift silently. A group rename in authentik, a changed attribute name in an upgrade or a removed user from a group can each change what an administrator sees without any error message. Test the complete path from group membership to FMC role after setup, and repeat the test after changes on either side.
- Positive test: Sign in as one user per role and confirm each sees only the permissions that role should have.
- Negative test: Sign in as a user outside all mapped groups and confirm access is refused.
- Change log: Record every group rename, attribute change and FMC authentication setting change with the date and owner.
- Upgrade re-test: Repeat the role tests after upgrading authentik or FMC, since either side may change how attributes are sent or read.
- Session behavior: Confirm how quickly a removed administrator loses access, since existing sessions may remain active until they expire.
Keep the test results with your change records so an auditor or reviewer can see how the role model was verified.
Hardening SSO for firewall administrators
Single sign-on moves the firewall login decision to authentik, so the security of administrator access now depends on the identity side as much as the firewall. The cards below cover the controls to set around the SAML login: who can reach an admin role, how sign-ins are checked and logged, how the signing certificate is replaced, and how the management interface stays reachable if authentik is down.
Enforce MFA in the authentication flow
Attach an authenticator validation stage to the flow that authentik uses for this SAML application, so every administrator must present a second factor before the assertion is sent to Cisco Secure Firewall Management Center. Check that the stage applies to the admin group and not only to a test user. Second-factor options such as TOTP, WebAuthn and Duo depend on edition and configuration, so confirm the available methods against the authentik pricing page and your own build before you commit to one.
Restrict membership of admin groups
Role mapping only protects the firewall if the groups that feed it are tightly controlled. Limit membership of the groups that map to Administrator or Access Admin roles to a short, named list, and keep those groups out of self-service enrollment and automatic sync rules. Review membership on a fixed schedule and remove accounts that no longer need firewall rights. Ask your team who can add a user to these groups, since that person can grant firewall control.
Rotate the SAML signing certificate
The certificate that authentik uses to sign SAML assertions must be imported into Cisco Secure Firewall Management Center, so rotation is a coordinated change, not a routine task. Plan a window where both the old and new certificates are accepted, import the new certificate on the firewall side, test an administrator login, then retire the old one. Record the expiry date of the current certificate in your change calendar and confirm the exact import steps in the integration guide.
Keep a break-glass local admin
Keep at least one local administrator account on Cisco Secure Firewall Management Center that does not depend on authentik. Store its credentials in a sealed record under separate control, such as a sealed envelope in a safe or a vault owned by a different team, and require two people to access it. Test that the account still works after each major change, and record every use so that an emergency login is visible during review.
Log and review administrator sign-ins
Forward authentik sign-in and authorization events to your central log platform, and keep the matching Cisco Secure Firewall Management Center audit records alongside them. Build a simple check that matches each firewall admin session to an authentik login with MFA recorded. Confirm which authentik events are available in your edition, since enhanced audit logging is listed as an Enterprise feature on the pricing page.
Limit the management interface to approved networks
Single sign-on does not stop an attacker who can reach the login page from the internet. Restrict the Cisco Secure Firewall Management Center web interface to administrative subnets or a jump host, and make sure the authentik endpoint used for the redirect is reachable only from the networks your administrators use. Test both paths: a permitted administrator login and a denied attempt from an unapproved network. Document the allowed ranges and who approves changes to them.
Why FMC SAML logins fail and how to fix them
This table lists the most common reasons SAML sign-in from authentik to Cisco Secure Firewall Management Center breaks, with the likely cause, the check to run and the fix for each. Work through the rows in order when a login fails, and confirm exact error text in both the FMC and authentik logs before changing settings.
| Failure | Likely cause | Check and fix |
|---|---|---|
| Signature validation fails after rotation | authentik signing certificate was rotated or replaced, but FMC still trusts the old certificate | Compare the certificate in the authentik provider with the one uploaded to FMC. Re-import the current certificate into FMC, then retest. Confirm the exact SAML error in the FMC log. |
| Clock skew rejects assertions | Time on the FMC appliance or the authentik hosts drifts, so assertion validity windows appear expired or not yet valid | Check NTP status on FMC and on every authentik node and worker. Correct time sources, then retry. Confirm the error refers to timing before changing certificates. |
| Entity ID mismatch | The entity ID in the authentik SAML provider differs from the value entered in FMC, including trailing slashes or case | Copy the entity ID exactly from the authentik provider and paste it into FMC without edits. Retest sign-in from a clean browser session. |
| ACS URL mismatch | The assertion consumer service URL in authentik does not match the FMC login address, often because of a different hostname, port or HTTP versus HTTPS | Confirm the FMC URL users actually open and set the ACS URL in authentik to match it. Check the integration guide for the expected binding before changing it. |
| User lacks a mapped role | The authenticated user is in no group or attribute that FMC maps to an administrative role, so sign-in succeeds but access is denied | Review the group or attribute the assertion sends for that user. Add the user to a mapped group, or extend the role mapping in FMC. Confirm the attribute name and value in the authentik logs. |
| MFA prompt loops | The authentik flow re-prompts for a factor the browser cannot complete, or the session is reset between the SAML request and the callback | Check which authentication stage repeats and whether the user has a working second factor enrolled. Review session and cookie settings on the authentik domain, then test with a new user. |
| All administrators locked out | Role mapping or certificate changes broke every SAML login, and no local administrator was kept for recovery | Use a local FMC administrator account that was preserved before the change to revert the SAML settings. Restore the last known good certificate and mapping. Keep a documented local recovery account in every future change plan. |
Questions buyers ask before configuring Cisco FMC SAML
Can our in-house team configure authentik SAML sign-in for Cisco FMC on its own?
Yes, a team with authentik administration skills and Cisco FMC administration skills can usually do it in-house, provided it has the time and a safe place to test. The work spans two systems: an authentik SAML provider and application on one side, and the FMC external authentication object, attribute mapping and role assignments on the other. The main risk is not the first login but locking out every administrator, so the team should keep a local FMC administrator account working throughout. Confirm that your engineers have change rights on both systems and can test without touching production sessions.
What drives the effort of an FMC SAML integration?
Effort follows the shape of your access model more than the login itself. The main drivers are:
- The FMC version and whether SAML external authentication is available on it, which you should confirm against Cisco's documentation for your release.
- The role model: how many FMC roles you map, and whether roles come from group membership or from a custom attribute.
- The number of admin groups in authentik and in your directory, and how cleanly they map to those roles.
- The MFA design, including whether MFA is enforced in authentik for every admin or only for some groups.
- The change window available for testing and cutover.
Each additional role or group multiplies testing, so ask for the role matrix in writing before scoping.
How long does an FMC SAML integration take?
Duration depends on scope and on how many environments you need, so no fixed figure applies. A single FMC instance with a small, well-defined role model and an existing authentik deployment is a much smaller job than a multi-FMC estate with custom attributes, several identity sources and formal change control. Ask for a schedule that separates design, build in a test FMC, role verification, and the production change window, and ask which of those steps depend on your change board or on Cisco-side tasks.
What do we need to provide for the integration?
Plan for three inputs before the work starts. First, identity owners who can confirm which groups grant which FMC role and who approves changes to them. Second, network access from the authentik server to the FMC management interface, and from your browsers to both systems, plus the FMC hostname and certificate details. Third, a test window in a non-production FMC or a planned maintenance slot, so that a failed role mapping does not block administrators during business hours. Missing any of these usually extends the timeline more than the technical work does.
Does the open-source edition of authentik support this integration?
The integration is built on SAML, and SAML provider types are part of the authentik provider set, so the core capability is not what separates the editions. The pricing page lists three editions: Open Source at no cost with community Discord support only, Enterprise at a per-user monthly price billed annually plus a per-external-user charge, and Enterprise Plus starting at an annual price. Enterprise-only features on that page include Google Workspace and Microsoft Entra ID integrations, mTLS, privileged access management and enhanced audit logging. Check the authentik pricing page for current terms, and confirm with the vendor that your required features fall into the edition you choose.
What should we confirm about FMC SAML support on our version?
Confirm three things before scoping. First, that your FMC release supports SAML single sign-on for administrator logins, and which configuration options it exposes. Second, which attributes or group claims the FMC version can use for role assignment, since that determines whether groups or a custom attribute must be sent from authentik. Third, whether the FMC supports the signing and encryption settings you plan to use, and what certificate format it expects. Use the authentik Cisco FMC guide as the starting point, then verify each point against Cisco's documentation for your exact version.
Should MFA be enforced in authentik or in the FMC?
Enforce MFA in authentik, at the point where administrators sign in through SAML, so that every SAML login passes through the same second-factor policy. Enforcing it only in the FMC can leave the design split across two systems that drift apart over time. Decide which authentik groups require a second factor, which factor types are allowed for administrators, and how recovery works if a device is lost. Keep the local FMC emergency account out of this flow and protect it with its own credential handling.
Testing FMC SSO before you lock out local admins
Do not restrict local login until SAML sign-in to Firewall Management Center has been tested end to end. The safe order is to build the authentik SAML application and the FMC external authentication object in a lab or non-production FMC first where one is available, then move the same settings to production only after each step passes. Keep the local administrator account enabled and known to at least two people during every stage. If the SAML path fails after local login is disabled, recovery depends on that account and on console or appliance access you have arranged in advance.
Test one user per role you intend to grant, not just one administrator. Sign in as each test user through authentik, confirm that the FMC role matches the group membership in authentik, and confirm that the user cannot exceed that role. Include a user with no group membership and a user removed from a group, because those cases show whether access is revoked when it should be. Check that MFA is enforced in the authentik flow for each test user and that the sign-in is recorded in the FMC audit log and in the authentik event log. Run the break-glass check last: sign in with the local account after SAML is enabled, make a harmless change, and confirm it is logged. Confirm the exact role mapping and attribute names against the authentik integration guide for Cisco FMC and your FMC version, since the guide is the source for this setup.
For an access review, keep records that show the design and the test result, not a claim about compliance. Retain a dated export or screenshot of the authentik application, provider and group bindings, the FMC external authentication settings with secrets removed, the role mapping table, the test matrix with each user, role and result, and the audit log extracts for those sign-ins. Record who approved the change and when local login was restricted, and store the break-glass procedure with its last successful test date. Ask your auditor which of these artifacts they expect, because independent assessors decide what is sufficient, and DeployOpen prepares the evidence without issuing any audit outcome.
How the SAML integration fits together
This integration moves Cisco Secure Firewall Management Center (FMC) administrator sign-in from local accounts to authentik, so authentik decides who can reach the management interface and with which role. The authentik integrations guide for Cisco FMC configures SAML single sign-on from authentik to FMC. Treat it as administrative access, separate from VPN user access, with its own application, groups and MFA policy. Before you start, decide which local FMC account stays available for break-glass access if authentik or the SAML exchange fails, and confirm in the FMC documentation how that account is kept.
Three decisions shape the build. First, choose the authentik groups that map to FMC roles, and keep the mapping in a short, reviewed table so that each FMC role has one named owner in authentik. Second, confirm which user attribute or group claim the SAML assertion must carry for FMC to assign a role, and check the exact attribute names against the guide, since they are not something to assume. Third, decide where MFA is enforced. Because the second factor belongs to the authentik authentication flow, it applies to every sign-in that passes through the application, so the policy must be bound to the FMC application and not only to a general login path.
Plan the work as a test-first change. Confirm that your FMC version is covered by the guide and that your authentik version is one you run on a supported release line, since security fixes apply only to the versions listed in the authentik security policy. Use a non-production FMC if you have one, and test with a standard administrator, a read-only user and a user outside every mapped group. Also schedule signing certificate rotation and the process for updating the identity provider metadata in FMC. Licensing for SAML providers is not on the authentik enterprise-only list, but confirm the edition you need with the authentik pricing page before you commit.
