Apache NiFi SSO and identity integration starts with who can change live data flows
Many NiFi instances that now need named access began with a shared admin login, a single-user account or an LDAP bind that a whole team uses. When the security team asks who changed a processor, who stopped a flow or who can view data in a sensitive pipeline, those setups cannot answer. Single sign-on in NiFi means choosing one supported authentication method, which is OpenID Connect, SAML 2.0, LDAP or X.509 client certificates, and then mapping identity groups from that source to NiFi access policies. The authentication method decides who can sign in, and the policy mapping decides what each person can change after signing in. Both decisions need to be settled before a production cutover.
The policy side is where these projects usually slip. NiFi authorizes access per component and per action, so a group that can view a flow component does not automatically have the rights to start, stop or edit it, and viewing a component is governed separately from changing it. Map each operating role to the smallest set of policies it needs, and write the mapping as a table that your reviewers can read without running the instance. Two other points shape the plan. The Kerberos provider is deprecated, so a Kerberos-based directory needs a different target before go-live. Single-user mode is a bootstrap tool for initial setup and should not be treated as the way a team operates the platform.
Mapping mistakes have a direct cost. If the group or claim your provider sends does not match what NiFi expects, the administrators who configured the change may be unable to sign in. Keep a documented break-glass path that you can use before you change the authentication method, and test it on a non-production instance first. Identity work also cannot be finished in isolation. When no security configuration is provided, NiFi binds to 127.0.0.1, so the UI is reachable only through the loopback interface. Users on other hosts cannot reach the UI until a secure configuration exists, which means the identity and TLS workstreams usually have to be planned together.
Before choosing a method, confirm four things with your identity team: which protocol your provider supports cleanly, which group attributes it can send, how your directory groups map to operating roles, and who holds the break-glass account. Apache NiFi is licensed under Apache-2.0 and the project offers no paid edition, so the cost of this integration sits in internal staff time, testing and any partner work, not in a license fee. Check the NiFi System Administrator's Guide for the configuration properties that apply to your chosen method and to the NiFi version you run, because those details can change between releases.
Which NiFi authentication providers and settings are involved
An SSO build for Apache NiFi touches more than one login screen. The authentication provider, the properties that switch it on, the access policies that decide what each identity can do, and the transport security that must exist before the UI leaves the loopback interface all have to agree before a single user signs in.
Supported user authentication options
NiFi supports single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate authentication, according to the NiFi administration guide. Choose the option that matches your identity provider and how users reach the UI, then confirm the exact configuration steps for your NiFi version in that guide. Each option has its own dependencies, such as a trusted certificate chain, a directory connection or a registered relying party, so review those before you commit to a design.
Single-user authentication
Single-user mode uses one local username and password and is the simplest way to put a NiFi instance behind a login. It does not map individuals to roles, so every administrator shares one identity and audit trails cannot show who changed a flow. Plan to move off it before production use with more than one operator, and confirm in the administration guide how the credential is set and rotated for your version.
LDAP directory authentication
The LDAP provider checks user credentials against a directory such as Active Directory or OpenLDAP. It depends on a reachable directory service, a bind account, correct search bases and filters, and TLS on the connection so credentials are not sent in clear text. Group membership in the directory is a separate concern: it must reach NiFi in a form your access policies can use, so test the group lookup as well as the login.
OpenID Connect and SAML 2.0 federation
OpenID Connect and SAML 2.0 hand login to your identity provider, so NiFi relies on the provider's sessions, multi-factor policy and lifecycle controls. Both need a registered client or service provider, redirect URIs that match the NiFi hostname exactly, and a claim or attribute that carries group or role data. Confirm which claims your NiFi version reads and how your provider names groups before building the mapping.
X.509 client certificate authentication
Client certificate authentication identifies users by a certificate presented during the TLS handshake. It suits automated clients and environments with a managed public key infrastructure, but it depends on certificate issuance, revocation checks and a rule that turns a certificate subject into a NiFi identity. Plan certificate renewal and revocation as operational tasks, because a lapsed certificate blocks access just as a disabled account does.
Deprecated Kerberos provider
NiFi's administration guide marks the Kerberos provider as deprecated, so it should not be the basis of a new SSO design. Existing deployments that rely on it need a planned move to a supported option, with their users, groups and any service principals mapped to the new provider before cutover. Confirm the deprecation status and any removal timeline against the current administration guide for your release.
Properties that enable a provider
Each authentication provider is enabled through NiFi properties in its configuration files, and the settings for one provider can conflict with another if both are left partly configured. Keep a single authoritative set of property values under version control, record which provider is active for each environment, and check each change against the administration guide for the version you run, since property names differ between releases.
Access policies for users and groups
Authentication only proves who the user is. Access policies decide what that identity may do, such as viewing or modifying a process group, administering the cluster or viewing data provenance. Map each identity provider group to a deliberately small set of policies, assign them before go-live, and keep an administrator path that still works if the directory or federation provider is unavailable.
Security configuration before binding beyond 127.0.0.1
Without a security configuration, NiFi binds to 127.0.0.1 so the UI is reachable only through the loopback interface, according to the NiFi administration guide. Binding to a network address requires TLS for the UI and a configured authentication provider first, so that no user reaches an unauthenticated interface. Confirm the required keystore, truststore and HTTPS settings in the guide, and test the sequence in a non-production environment before opening the port.
Choosing OpenID Connect, SAML 2.0, LDAP or X.509 for NiFi
This table compares the NiFi authentication options by the situation each one fits and the operational work each one adds. Read each row against your own identity estate, then confirm provider behavior for your NiFi version in the administration guide. The main takeaway is that the provider you pick sets your certificate, directory and IdP dependencies for the life of the cluster, so choose it before cluster node access is designed.
| Option | When it fits | Operational cost | Watch for |
|---|---|---|---|
| OpenID Connect | You have a corporate IdP that issues OIDC tokens and users sign in through a browser | Client registration and redirect URI setup, claim mapping to NiFi identities and groups, and IdP availability for every user login | Confirm which claims NiFi reads for identity and group mapping in your version, and test group changes end to end |
| SAML 2.0 | Your corporate IdP is SAML-first and issues assertions for web applications | Service provider metadata exchange, signing and encryption certificate renewal, and attribute mapping for identity and groups | Certificate expiry in metadata is a common outage cause, so track it with the IdP team |
| LDAP | Users and groups live in a directory and you do not run a federated IdP for NiFi | Bind account management, directory query load from logins and group lookups, and TLS configuration to the directory | Confirm group search settings and how often NiFi refreshes group membership in your version |
| X.509 client certificates | Machines, automated clients or services need access without interactive login | Issuing, distributing, rotating and revoking client certificates, plus trust store maintenance on NiFi | Certificate lifecycle is the main effort, and revocation handling must be verified against your PKI |
| Single-user mode | Recovery or bootstrap only, such as first access to a fresh node or restoring access after a provider fault | One shared credential that must be protected and removed from normal operation once a real provider is working | Do not run it as the production design, and confirm current behavior in the administration guide for your version |
| Kerberos provider | Legacy estates that already depend on it and cannot yet move | Keytab and KDC dependency with a provider that the NiFi project has deprecated | Not a suitable target design, so plan a move to a supported provider as part of the migration |
How to connect NiFi to an identity provider step by step
This sequence moves NiFi from a loopback-only install to a cluster that signs users in through an identity provider, maps their groups to access policies, and keeps a documented fallback account. Each step closes with a check the team can run before moving on. Confirm the provider-specific property names in the administration guide for your 2.x build before you apply them.
Confirm the target NiFi 2.x release
The platform owner confirms that the target is a 2.x release. NiFi 2.12.0 was released on September 13, 2026, and the 2.x line is the supported path because 1.x depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, which cannot be upgraded within that line. Record the chosen version and the binaries every node will run, and confirm they match the release listed on the Apache download page. Done when the version appears in the change record and every node's artifact checksum matches the published one.
Confirm Java 21 on every node
The platform team installs Java 21 on each node and checks each host individually, since the administration guide lists Java 21 as the minimum runtime. Nodes in one cluster must run the same version, and any host that is missed will fail to start cleanly or join the cluster. If the team plans to use the optional Python-based processors, it also confirms Python 3.10, 3.11 or 3.12, noting that the guide describes these processors as a beta feature. Done when the Java version output is identical on all nodes and NiFi starts on each one.
Enable TLS and remove loopback binding
The security team issues the server certificate and manages the keystore and truststore, and the platform team sets the HTTPS host, port and store locations in nifi.properties. Without a security configuration, NiFi binds to 127.0.0.1, so this step is what makes the UI reachable from the corporate network. Confirm the exact property names against the administration guide for your 2.x build. Done when a browser on a workstation outside the node's loopback interface loads the HTTPS login page and the certificate chain is trusted.
Register NiFi in the identity provider
The identity team creates NiFi as an application in the provider. For OpenID Connect, it registers a confidential client and stores the client secret in the team's secrets store, not in a shared document. For SAML 2.0, it prepares a service provider entry from NiFi's metadata. The redirect or assertion consumer address must match the HTTPS hostname from the previous step exactly. Done when the provider's application record shows the correct redirect value and a pilot group is assigned to the application.
Configure the provider and redirect values
The platform team enables the chosen provider in NiFi's login identity provider configuration and points nifi.properties at it. For OpenID Connect, it enters the discovery address, client ID, secret and the claim that carries group membership. For SAML 2.0, it loads the provider metadata and maps the group attribute. LDAP is also supported. Restart nodes one at a time under the change process. Done when a pilot user signs in through the provider, lands in NiFi, and that user's group claim is visible in NiFi's user list or logs.
Keep one administrative fallback account
Before any single-user access is removed, the security and platform leads create one administrative fallback account and document who controls its credentials. Store the secret in a sealed location that two named custodians can reach, and write a short procedure stating when it may be used and how the use is recorded and reviewed. Confirm with the vendor documentation which fallback mechanism your 2.x build supports. Done when the custodians confirm the credential opens NiFi on a test node and the logins appear in the audit trail.
Map groups to initial access policies
The platform team maps provider groups to NiFi policies in authorizers.xml and the NiFi policy interface, and sets the initial admin identity so the first administrator can sign in. The admin group receives access to controller settings, policies and tenants. The data-flow group receives read and write access only on the process groups it owns. Done when an admin-group user can open Policies, a data-flow user can start a process group it owns, and a user with no matching policy receives a denied response for the same action.
Remove or lock down single-user access
The platform team removes the single-user provider from the active configuration on every node, once the fallback account has been tested. The Kerberos provider is deprecated according to the administration guide, so the design should not select it for new work. Check that the single-user configuration is gone from each node, not only from one. Done when a single-user login attempt is refused, the provider-backed user still signs in, and the fallback path has been tested end to end.
How identity groups map to NiFi policies
The core decision in this section is that authentication and authorization are separate steps, and only the first one is handled by your identity provider. When a user signs in over OpenID Connect, SAML 2.0 or LDAP, NiFi establishes who the user is. What that user may do is decided by NiFi's own access policies, which grant rights to users and groups on specific components: a flow or process group, a controller service, or the cluster itself. Group membership from the directory only matters if NiFi receives that group information and a policy references it. Before you configure anything, confirm in the NiFi administration guide for your version how the group claim or attribute is passed through each authentication method, and which attribute NiFi uses as the identity and as the group name.
Group names must match exactly across the identity provider and NiFi. A group called DataEngineers in the directory and data-engineers in a policy will silently grant nothing, and users will see empty canvases rather than an error. Agree a naming convention with the identity team before the first policy is written, covering case, separators, and whether groups carry an environment prefix. Record the mapping from each directory group to each NiFi policy in a single register that names the policy owner. This register is the document an auditor or a new administrator will need, and it is much cheaper to keep current than to reconstruct from the running cluster.
The main risk is granting broad component-level rights. A policy that gives a group access to the root process group or to global controller service rights reaches every flow beneath it, including flows that handle sensitive data. Start from the smallest scope that works and widen only when a real need appears. A practical starting point is a small set of role groups, such as data engineers who build and change flows, flow operators who start, stop and monitor them, auditors who read provenance and configuration without changing anything, and cluster administrators who manage nodes and global policies. Keep the cluster administrator group very small. Illustrative example: a data engineer group might be given write rights on one team's process group only, with no rights on the root group. Confirm the exact permission names and their default sets for your NiFi version in the administration guide before you copy any such design.
Test every group membership change in a non-production cluster before it reaches production. Use a test identity provider or a test group that mirrors the production names, add a test user, sign in, and check what that user can see and change. Check both positive and negative cases: the user should reach the flows they need and be refused on the flows they do not. Also test removal, since a user who leaves a group should lose access at the next sign-in, and confirm how long existing sessions remain valid in your configuration. Repeat the checks after any change to the authentication settings, because a change to the claim or attribute name can break mapping for every user at once.
Operationally, treat policy changes as controlled changes. Keep the policy register under version control or in the same system that holds your identity provider configuration, and require a named owner to approve changes to any policy that touches the root group, global rights or sensitive data flows. Review group membership on a schedule agreed with your security team, and confirm with your auditors what evidence they expect, such as exports of policies and membership lists. DeployOpen can help define the role groups, build the register and prepare the test cases, but the group owners in your organization must approve who belongs in each group.
What drives identity integration effort in NiFi
This table lists the factors that move effort and cost when connecting NiFi to an identity provider, and how to keep each one contained. Read each row as a lever: the cost of a driver usually comes from how many identities, groups, nodes and environments the integration has to cover. The main takeaway is that a small set of role groups, one identity provider application per environment and one reusable provider configuration pattern keeps the work bounded.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Identity sources and federation | Each source that must be federated adds provider configuration, claim mapping and testing. Multiple IdPs for one NiFi cluster need a clear rule for which one wins. | Federate through one primary IdP where possible. Confirm with your identity team whether a second source is truly required before scoping it. |
| Groups and policy scopes | Every group mapped to a NiFi policy adds access rules to design, review and test. Fine-grained policies on many process groups multiply this work. | Use a short list of role groups, such as operators, developers and read-only viewers. Grant policies on process group roots rather than individual components. |
| NiFi nodes and environments | Each node must trust the same provider settings and certificates. Dev, test and production each need their own redirect URIs, secrets and verification. | Use one identity provider application per environment. Keep node configuration templated so every node and environment uses the same provider pattern. |
| Shared or separate IdP and NiFi teams | When one team owns both the identity provider and NiFi, decisions and change requests move faster. Separate teams add handoffs for every client, claim or group change. | Agree in advance who approves claim names, group names and redirect URIs. Record that split in the scope so change requests are predictable. |
| Change control and certificate management | Changes to OIDC, SAML or LDAP settings often need approval windows. Certificate rotation for SAML signing or TLS affects every node at once. | Batch configuration changes into scheduled windows. Document certificate owners and expiry dates, and rehearse rotation in a non-production environment first. |
| Compliance evidence needs | Assessors often ask for proof of who can access flows, how access was granted and how changes were approved. Gathering that evidence after the fact is slow. | Decide early which access reviews, logs and approval records you need. Confirm the evidence format with your auditor before configuration starts. |
| Existing flows needing permissions re-applied | Moving from single-user mode or an older access model means existing flows and components need new policies. Effort rises with the number of process groups and controller services. | Inventory process groups before cutover and group them by owning team. Re-apply policies to the parent group so child flows inherit access where the design allows. |
Hardening identity access in NiFi
Connecting NiFi to an identity provider changes who can reach the UI and what they can change, so the controls below need to be in place before users log in through SSO. Each card covers a control that is specific to identity integration, and the order of the cards roughly matches the order in which teams should apply them.
TLS before non-loopback access
NiFi binds to 127.0.0.1 when no security configuration is provided, so the UI is reachable only from the host itself. Before you open the UI to other networks or configure an OpenID Connect, SAML 2.0 or LDAP provider, enable HTTPS on the UI and secure node-to-node communication. Confirm that the certificates your identity provider trusts match the hostnames NiFi advertises. The detailed TLS and keystore setup sits in the security hardening topic.
Client credentials kept out of flows
OpenID Connect and LDAP bind credentials, such as a client secret or a service account password, should not be typed into controller service properties in a flow that is exported or versioned. Store them as sensitive values and supply them from a parameter context or a secrets source that your team controls. Check that exported flow definitions and Git repositories contain no credential values, and confirm how the sensitive properties key is managed across nodes.
Retiring single-user credentials
Single-user authentication is useful for bootstrapping and for recovery, but it is a shared local account outside your identity provider. Once an SSO login has been tested with a representative set of administrators, remove the single-user credentials or disable the path, and record who approved that change. Keep the removal in the change log so auditors can see when local access stopped being the normal way in.
Limiting who edits access policies
In NiFi, the ability to change access policies is itself a privileged permission, because a user who can edit policies can grant themselves everything else. Assign that right to a small, named group of platform administrators, mapped from a group in your identity provider. Review the policy-editing group on a regular schedule and confirm that changes to it are logged and traceable to a person.
Kerberos provider as a migration item
NiFi lists the Kerberos provider as deprecated, so an installation that relies on it has a migration task rather than a settled configuration. Inventory every user and service that authenticates through Kerberos, then map each one to OpenID Connect, SAML 2.0, LDAP or X.509 client certificates. Plan the cutover as its own change with a rollback step, and confirm the target provider with your identity team before scheduling it.
A tested administrator fallback path
Removing single-user access is safe only if another way back into NiFi is documented and has been used. Write down the fallback steps, such as which authorizers file or group entries to restore and who holds the keys to the identity configuration. Rehearse the fallback in a non-production cluster and record the result. Repeat the test after each identity provider certificate renewal or group mapping change.
How to test that SSO works and fails safely
The test plan for NiFi SSO should answer two questions before go-live: can the right people get in, and does the system refuse everyone else when identity fails. Treat these as separate test suites with separate evidence. A useful plan covers positive tests, negative tests, a fallback test and, for clustered deployments, a restart or node-failure test. Write the expected result for each test before running it, so the outcome is a comparison against a stated expectation rather than a judgment made after the fact. Positive tests confirm that a member of each role group can sign in through the configured provider (OpenID Connect, SAML 2.0 or LDAP, depending on the design) and sees only the flows and components their policies allow. Pick one test account per group, including at least one account that belongs to several groups, because multi-group users often expose mapping mistakes. Negative tests should cover three cases: a user outside every authorized group is refused, an expired or revoked session cannot reach the UI or API, and a user removed from a group loses access on the next session rather than at some later point. Ask your identity team how long a removed user's existing token or session remains valid, since this sets the maximum exposure window you can honestly report. The fallback test checks the documented administrator path. Stop or block the identity provider in a non-production environment and confirm that the break-glass administrator can still reach NiFi, and that ordinary users are refused rather than silently given access. Confirm the exact login mechanism for the fallback path in the NiFi administration guide for your version, and do not assume it behaves like the normal path. For clustered deployments, also restart a node and fail a node during an active session, then confirm that authentication state, policy checks and access to flows remain consistent across the cluster. Coordination for leader election (ZooKeeper or Kubernetes state) should be part of this exercise, since a failed coordinator can look like an authentication fault. Capture evidence for each test in a form an auditor or security reviewer can reproduce. Record the test ID, the account used, the expected result, the observed result, the timestamp and the tester. Screenshots of refused and permitted screens are useful, but they are weak alone, so pair them with configuration exports taken after secrets have been removed, the identity provider group membership at the time of testing, and the change record that approved the configuration. A successful login does not prove that authorization is correct: a user can authenticate perfectly and still hold a policy that is too broad. For that reason, keep policy tests in their own suite, checking what each group can see and change against the access matrix, and do not count a passed login test as a passed authorization test.
Questions teams ask before connecting NiFi to SSO
How much effort does NiFi SSO integration usually take?
The effort depends mainly on scope and decisions, not on NiFi alone. The main drivers are the number of identity sources (OpenID Connect, SAML 2.0, LDAP or a mix), how many groups must map to NiFi access policies, and how much review each mapping needs. Work also grows when every NiFi node must be reconfigured and tested as one cluster, when TLS is not yet in place (the login flows depend on it), and when service accounts or certificate-based access must keep working alongside people's logins. Moving users off single-user mode and retiring any Kerberos dependency add further steps. Ask for the effort to be sized from a written inventory of your identity sources, groups and cluster nodes rather than from a generic estimate.
How long does an SSO project for NiFi take?
Timing depends on three things: identity sources, policy design and change control. Identity sources set the pace because the identity team must create the application registration, emit the right group claims and provide test users for each group. Policy design takes time when owners must agree who gets read, write and administrator rights on each flow area. Change control adds lead time when production changes to clustered nodes need approval and a maintenance window. Because these vary by organization, the schedule should be fixed in the written scope before work starts, with milestones for identity setup, a test cluster, production cutover and rollback. Treat any duration you hear before that document exists as a guess.
Can our own team set up NiFi SSO without a partner?
Yes, if your team owns both the identity provider application setup and NiFi administration. Your team would configure the IdP application, TLS, the authentication provider and the authorizer settings, then map groups to policies. The trade-offs are the learning curve on login flows, token and group claim behavior, and failure modes, plus the need for someone who can test a rollback without locking out administrators. Your team also owns every later change, such as adding a provider or rotating a signing certificate. A partner can shorten that path and leave a written test record, but the choice depends on the skills, time and on-call capacity you have in-house today.
What do the identity team and the NiFi team each need to provide?
Both teams have defined inputs, and the work stalls when either is missing. The identity team usually provides the application registration in the IdP, the redirect addresses for the NiFi hostnames, the claims or groups to include in the login response, test accounts in each group, and a named owner for signing certificate renewal. The NiFi team provides TLS certificates and trust stores for each node, access to the NiFi configuration files and authorizer settings, the inventory of cluster nodes, the list of groups and the access each one needs, and a maintenance window. Both teams should name an approver for policy changes and agree on the test plan before the first change is made.
Can NiFi still use Kerberos authentication after moving to SSO?
Kerberos can still run in some setups, but the NiFi administration guide lists the Kerberos provider as deprecated, so plan a migration. The supported alternatives in the guide are OpenID Connect, SAML 2.0, LDAP and X.509 client certificates, and the right choice depends on what your directory and identity provider support. A practical sequence is to inventory every user and service identity that depends on Kerberos, map each one to a replacement provider, test the change in a non-production cluster, cut over, and then remove the Kerberos settings. Confirm in the administration guide for your exact NiFi version how the deprecated provider is handled before you set a date for the change.
Can single-user mode stay enabled after SSO goes live?
Keep single-user mode only as a documented fallback, not as an everyday login path. It relies on one shared account, which weakens individual accountability in audit records and gives anyone who holds the credential broad access. A fallback is reasonable when it is restricted to a small named group, its credential is stored securely and rotated, and every use is logged and reviewed. The same care applies to exposure: when no security configuration is provided, NiFi binds to 127.0.0.1 and the UI is reachable only through the loopback interface, so opening the UI to users requires deliberate TLS and authentication configuration first. Write the break-glass procedure before cutover so the team can use it under pressure without improvising.
What should a fixed-scope quote for NiFi SSO include?
A fixed-scope quote should name every system and decision the work touches, so both sides can see what is included. Ask for the protocols and providers in scope, the node count and cluster topology, the identity source inventory, and a group-to-policy mapping table. The quote should also cover TLS work, any Kerberos migration, the handling of single-user mode, test environments and test cases, the cutover and rollback plan, documentation and handover, and acceptance criteria. List the dependencies on your identity and NiFi teams with named owners, and state the exclusions and assumptions in writing, including change control. Compare quotes on this list rather than on the headline number alone, and ask the provider to explain how each line was sized.
How DeployOpen scopes, builds and hands over NiFi identity work
DeployOpen plans, implements and documents Apache NiFi SSO and identity integration inside your own infrastructure, using OpenID Connect, SAML 2.0 or LDAP as agreed in the written scope. Engagements are fixed-scope, so the identity provider, group-to-policy mapping and cutover steps are agreed in writing before work starts.
How we scope
- Confirm which identity provider, protocol (OpenID Connect, SAML 2.0 or LDAP) and NiFi versions are in use
- Inventory current single-user accounts, certificates and any Kerberos dependencies that must be retired
- Agree the group-to-policy mapping and which NiFi access policies each identity group receives
- Record cluster topology, TLS requirements and the environments that need separate identity configuration
How we build
- Configure the chosen login provider in NiFi and test it on a non-production cluster first
- Map identity provider groups to NiFi policies, then verify access against a documented test matrix
- Replace single-user login and move off the deprecated Kerberos provider with a tested rollback path
- Test login behavior across every node in a cluster, including failover and session expiry
How we hand over
- Deliver configuration files, policy mappings and the test matrix with the results of each test run
- Document the steps to add users, rotate client secrets and change group mappings without a rebuild
- Walk your platform and security teams through the runbook and record the agreed handover acceptance steps
- Provide a list of open items to confirm with your identity provider owner before production cutover
How we support
- Ongoing support and upgrades are available as a retainer after go-live
- Review identity configuration again when NiFi minor releases or identity provider changes arrive
- Re-run the access test matrix after upgrades so policy mappings keep working as expected
- Keep the runbook current so your team can operate identity changes without DeployOpen involved
