Apache NiFi SSO with Microsoft Entra ID

How Apache NiFi single sign-on with Microsoft Entra ID works

If your production NiFi still uses a shared or generated login, the first change is to replace it with named users from Microsoft Entra ID. NiFi supports sign-in through OpenID Connect and through SAML 2.0, and this page covers both paths. Either way, the work is standard OIDC or SAML configuration against your Entra tenant, because NiFi does not ship an Entra-specific connector.

The split of responsibilities matters before you touch any setting. Entra ID proves who the user is and, where you configure it, supplies group names in the token or assertion. NiFi still decides what that user may do, through its own authorization policies on the root process group and on individual components. A user who signs in successfully but belongs to no mapped group will reach the UI with no useful permissions, so group design and policy design have to be planned together.

Two inputs drive most of the decisions that follow. The first is which identity claim NiFi will use as the user name, since the choice sets how existing policies and the initial admin identity are written and is hard to change later. The second is whether group names will come from the token or assertion, and how many groups each user carries. Confirm the group limits that apply to your Entra configuration and token type with Microsoft before you design around them. Keep a recovery admin account, defined outside Entra ID, so that a misconfigured provider cannot lock every operator out of the cluster.

What you need before configuring Entra ID sign-in

Entra ID sign-in touches your NiFi runtime, your certificates, your Microsoft tenant and your access recovery plan. Settle these six items before you touch the NiFi authentication settings, because a gap in any one of them tends to surface as a failed sign-in that is hard to diagnose.

NiFi 2 on Java 21 or later

The NiFi administration guide lists Java 21 as the minimum runtime, so confirm the JDK on every node matches before you change any authentication settings. Check that the NiFi version is a 2.x release and not a 1.x line, because the 1.x series can no longer be maintained. If you are still on 1.x, plan the migration first, since it is a separate piece of work. Confirm the JDK version with your own build team, not only from the host where you ran a test.

Entra ID tenant with app registration rights

Sign-in requires an app registration in the Microsoft Entra ID tenant that your users belong to, so someone with permission to register applications must be available during setup. Confirm who holds that role, whether your tenant restricts user consent, and who approves changes to redirect URIs and client secrets. Agree the owner of the registration before the work starts, because it affects how secrets are rotated later.

Identity flow and claim decisions

Decide how users and group memberships enter NiFi before you configure anything. Choose whether NiFi will read identity and groups from OpenID Connect tokens or SAML assertions, and which attribute will serve as the user identity. Also decide whether group membership will come from the token or from a directory sync. Write these choices down, because identity mapping rules and NiFi access policies depend on them.

HTTPS endpoints with trusted certificates

NiFi must be reachable over HTTPS on a hostname that users and Microsoft's sign-in flow can resolve, with a certificate that the browser and the identity provider trust. Without a security configuration, NiFi binds to 127.0.0.1, so the UI is reachable only from the host itself. Change the binding to the configured address and confirm you can load the UI from a user workstation before you test sign-in. Ask your PKI team to confirm the certificate chain and the hostname in the redirect URI.

Network path to Microsoft sign-in

Each NiFi node that handles a login needs outbound network access to the Microsoft sign-in and metadata endpoints, and the NiFi host must accept the callback traffic from users. Check egress rules, proxies and DNS in the data center or cloud network where NiFi runs, especially in restricted or segmented networks. Test the path from the actual NiFi host, because a workstation test can pass while the server cannot reach the endpoints.

Named recovery admin plan

Before you disable the single-user login, name at least one recovery administrator and decide how that person regains access if the identity provider or group claims fail. The account should be a named individual with a documented break-glass procedure, not a shared login. Record where the recovery credentials are stored, who may use them and how their use is reviewed. Confirm this plan with your security team before go-live.

Choosing OpenID Connect or SAML for NiFi

With OpenID Connect, NiFi acts as an OAuth 2.0 client registered in your Entra ID tenant. You give NiFi the discovery URL for the tenant, the client ID and client secret from the app registration, and the redirect URI that NiFi will use after sign-in. NiFi then reads the identity and group values from the ID token or user info response, so the claim you choose becomes the identity that policies match against.

Client registration: You create an app registration in Entra ID, add the NiFi callback URL as a redirect URI, and store the client secret in a managed secrets location. The secret has an expiry you must track.
Discovery and metadata: NiFi loads signing keys and endpoints from the discovery document, so key rotation at the identity provider is picked up without editing NiFi settings.
Identity claim: Choose a claim such as the user principal name or a stable object identifier. Confirm which claims your tenant emits before you write mapping rules.
Group claims: Group membership arrives as a claim in the token. Entra ID limits how many groups it places in a token and can replace large lists with an overage indicator, so plan for that case.
Token lifetime: Access and refresh behavior is governed by Entra ID policy, which affects how often users must re-authenticate.

Confirm the claim names, group limits and client secret handling against the NiFi administration guide and current Entra ID documentation before you commit to this path.

Registering NiFi in Microsoft Entra ID for single sign-on

This sequence connects a NiFi instance to Microsoft Entra ID so users sign in with their directory accounts, group membership drives NiFi policies, and a named admin group keeps control of the flow. Each step ends with a check that confirms the result before the next step begins.

Create the app registration in Entra ID
A tenant administrator creates an app registration for NiFi in the Microsoft Entra admin center, choosing a single tenant unless the organization has a reason for multi-tenant access. Record the directory (tenant) ID and the application (client) ID, and create a client secret or certificate for NiFi to use, noting its expiry date so rotation is planned. The step is complete when the tenant ID and client ID are saved in your secrets store and the registration appears in the app registrations list with the expected owner.
Set the redirect URI to the NiFi endpoint
In the app registration, add a web redirect URI that matches the NiFi HTTPS address and callback path exactly, including the host name users will type in the browser. Any mismatch between this value and the NiFi configuration causes the sign-in to fail after the Microsoft prompt. The step is complete when the redirect URI is listed under the web platform and a test request to the NiFi login page reaches the Microsoft sign-in screen without an error about an invalid redirect.
Configure the NiFi OpenID Connect provider
On the NiFi host, set the OpenID Connect properties in nifi.properties, using the discovery URL for the tenant, the client ID, the client secret and the redirect URI from the previous step. If you use SAML instead, configure the identity provider metadata URL and the entity ID that NiFi presents as a relying party. Restart NiFi and check the logs for a successful provider initialization with no errors about the discovery document or the client credentials. The step is complete when NiFi starts cleanly and the login page offers the Microsoft sign-in option.
Choose and expose identity and group claims
Decide which token claim NiFi will use as the user identity, such as the user principal name or email address, and confirm it is present in the ID token for a test user. Decide whether group membership will come from group claims in the token or from a directory group list, and check the Entra limits on group claims in the token configuration, including the overage behavior for users with many groups. Add or adjust the optional claims in the app registration and configure NiFi to read the same claim names. The step is complete when decoded token output for a test user shows the expected identity and group values.
Set the authorizer and initial admin group
Configure the NiFi authorizer so that a dedicated Entra group, named for NiFi administrators, is given the initial admin policies, and map the identity string to the format NiFi receives from the claim chosen in the previous step. Keep the group membership small and owned by the identity team, and do not grant admin rights to individual user accounts. The step is complete when a member of the admin group signs in and sees the policy and administration menus, and a user outside the group does not see them.
Test sign-in with a named test user
Sign in with a named test account that belongs to a non-admin group, then confirm the identity string NiFi displays in the user menu matches the expected value from the claim mapping. Check that the policy outcome for that group matches the access you designed, such as read-only access to a process group, and that the user cannot modify components they should not change. Repeat the test with a member of the admin group. The step is complete when both results are recorded and match the authorization design.
Retain a recovery admin before disabling other logins
Before turning off the generated single-user login or any other fallback, keep one recovery administrator account in a documented, access-controlled location, and confirm that it can still sign in through the configured method or a break-glass path your team has tested. Store the credentials under your secrets controls and record who can use them and under what conditions. The step is complete when the recovery path has been tested successfully and the fallback login is disabled only after that test passes.

Mapping Entra ID identities and groups to NiFi users and policies

This table compares each Entra ID source value with the NiFi field it feeds and the access decision it drives. Read it row by row before go-live, because a value that differs by one character between the token or assertion and the NiFi policy definitions will silently block a user or group.

Entra ID source	NiFi field it feeds	Decision it drives	What to confirm before go-live
Identity claim (user principal name or email)	The identity string NiFi shows for the user and matches against policies and the initial admin identity	Which name appears in provenance, audit events and policy entries	Which claim your identity mapping uses, the exact casing, and whether it includes a domain suffix
Object identifier (oid)	Stable user identity string, if chosen as the identity claim	Keeps policies intact when a user's UPN or email changes	Whether your team accepts opaque GUIDs in audit logs and how renames will be handled
Group object identifier	Group names or identifiers read from the group claim	Which NiFi groups receive policies on process groups and components	Whether the token carries group object IDs or names, and how many groups each user holds
Application roles	Role values read from the token, mapped to NiFi groups or identities	Coarse access such as admin or read-only, instead of per-group membership	Which roles are assigned to which users in the enterprise application and that they appear in the token
Initial admin group or identity	The value NiFi treats as the first administrator when no policies exist	Who can create the first policies and manage other users	That the value matches the token exactly and that a named recovery admin is documented outside Entra ID
Identity mapping rule (transform)	A pattern or replacement applied to the claim value before NiFi uses it	Normalizes casing, strips a domain, or maps a claim to a short username	That the rule is tested against a real sign-in and the transformed value matches the policy entries
Group claim filter or overage behavior	Whether all user groups arrive in the token	Whether policies apply to every group a user should hold	How Entra ID handles large group sets and whether groups are filtered to assigned applications
Changes to the claim after go-live	Existing user and group identities stored in NiFi policies	Future sign-ins may create new identities that do not inherit old policies	Plan a migration of policies to the new value and test with a non-production admin before changing the claim

Choosing the identity claim and handling group claims at scale

Choose an identity claim that stays fixed for each person, because NiFi stores policies against the identity string it receives at sign-in. In Microsoft Entra ID, the object identifier (oid) is a unique identifier that does not change when a person is renamed or moves to a new domain. A display name or user principal name can change, and if NiFi keys policies to either, a rename can strip access from the person who should keep it or hand old policies to someone else. An email-style value is easier to read in policy screens and audit logs, so many teams prefer it for that reason. If you take that route, confirm how the value is sourced and whether it can change in your tenant, and document the decision before the first policy is written, since changing the identity mapping later means re-creating those policies.

Groups reach NiFi only if the token or SAML assertion carries them, and how Entra ID returns them depends on the token type and the number of groups a user belongs to. Large group memberships can cause the identity provider to omit the full list and signal that the application must retrieve groups another way, so a user in many groups may sign in with fewer NiFi permissions than expected. The group count limit and overflow behavior differ by token or assertion type and can change over time, so confirm them in Microsoft's current documentation for the exact configuration you plan to use. Then test with an account that belongs to more groups than your heaviest production user. Also decide whether groups are emitted by object identifier or by display name, because names can change and break policy matches.

Limit NiFi to a small set of dedicated groups and assign only those to the enterprise application. A practical starting set is one group for NiFi administrators, one for each team that owns process groups, and one for read-only auditors, named by function so policy reviewers can read them. Create these as cloud groups, or sync them with Microsoft Entra Connect if they originate in Active Directory. Keep the recovery admin outside these groups so access survives a broken group claim. Review membership on the schedule your access governance process sets, and confirm with Microsoft how assignment required on the application behaves in your tenant before you rely on it to refuse unassigned users.

Hardening the Entra ID sign-in for production NiFi

Federating NiFi to Microsoft Entra ID moves the sign-in path to a service you do not run, so the controls below cover what happens when that service is unavailable, who gets admin rights, what travels in tokens and how secrets are handled. Each card names the reason for the control and the check that confirms it works in your environment.

Keep a recovery admin account

Keep one local recovery administrator that does not depend on Entra ID availability, and store its credentials under sealed access with a documented break-glass procedure. Without it, a tenant outage, a misconfigured app registration or an expired secret can lock every administrator out of NiFi. Verify by signing in with the recovery account while the OIDC or SAML path is deliberately disabled in a test environment, then confirm the account can still change policies.

Limit initial admin group membership

Map only a small, named Entra ID group to the initial admin identity in NiFi, and keep it separate from groups used for everyday flow work. Whoever holds that group can grant access to every process group, so membership should be reviewed on the same cadence as other privileged roles. Verify by listing the members of the mapped group, confirming each is an approved administrator, and testing that a user outside the group cannot open the policy editor.

Serve every endpoint over TLS

Use HTTPS for the NiFi UI and the OIDC or SAML callback endpoints, and register redirect URIs as exact known addresses rather than wildcards or loose patterns. A broad redirect URI lets an attacker who controls a matching path receive authorization codes or assertions. Verify by checking that each redirect URI in the app registration matches the NiFi host name and path character for character, and that plain HTTP requests to the sign-in path are refused.

Protect the client secret and rotate it

Store the OIDC client secret, or any signing material used for SAML, as a sensitive value using the sensitive properties approach rather than in plain configuration files, and set a rotation schedule with an owner. Secrets that never change remain valid for anyone who copied them. Verify by confirming the value is not readable in exported configuration, performing a rotation in a test cluster, and checking that sign-in still works on every node after the change.

Review the claims sent to NiFi

Decide which claims NiFi needs to identify users and read group names, and request only those scopes and attributes from the tenant. Extra claims copy directory data into NiFi logs, tokens and policy views without adding any access control. Verify by decoding a sample token from a test sign-in, confirming the identity claim and group claim are present, and confirming no unneeded personal attributes appear.

Disable single-user login after federation

Remove or disable the generated single-user login once federated access works and the recovery admin is confirmed, so that no shared password remains as an alternate way in. Keeping it open leaves a credential that bypasses Entra ID sign-in audit trails and conditional access. Verify by attempting a single-user login after the change and confirming it is refused, while the recovery administrator and federated administrators still reach the policy editor.

Common Entra ID sign-in failures in NiFi and how to fix them

This table pairs common Entra ID sign-in failures with NiFi with their likely causes and fixes. Read each row against the NiFi log and the Entra ID sign-in log for the same attempt, since the two usually show different halves of the same failure. Confirm exact error text against current vendor and NiFi documentation before changing settings.

Symptom	Likely cause	Fix
Entra ID shows a redirect or reply URL error after sign-in	The redirect URI registered in the app registration does not match the NiFi address the browser uses, including scheme, host name, port or path	Register the exact NiFi callback URL in the app registration, matching the host name users type, then retry in a private browser window
Browser reports a certificate trust error on the NiFi login page	NiFi's HTTPS certificate is not issued for the host name users use, or the issuing certificate authority is not trusted by the user's device	Reissue the certificate with the correct host name in its subject alternative names and distribute the issuing CA to client devices
User signs in but sees no policies or cannot open any component	The group claim is missing from the token, or group values arrive as object IDs or names that do not match the group names in NiFi's authorizer	Confirm the token includes the groups claim for that user, choose the claim format NiFi expects, and align group identifiers in the authorizer
Existing policies stop applying after a change of identity claim	The identity string changed, for example from a user principal name to an email address or object ID, so it no longer matches existing policy entries	Review the identity mapping pattern, add a mapping that produces the original identity string, or recreate the policy entries under the new identity
Sign-in fails intermittently with token validation or metadata errors	Clock skew between NiFi and Entra ID, or identity provider metadata or signing keys that have rotated and are cached with old values	Synchronize NiFi host time with a trusted source, check the metadata URL is reachable, and refresh the configured metadata or discovery values
Users cannot reach NiFi from another machine after SSO is enabled	NiFi is bound to the loopback address 127.0.0.1, which is the default when no security configuration is provided, so the UI is only reachable locally	Set the HTTPS host and port in the NiFi properties to a reachable interface and confirm the firewall and load balancer route to it
Admin cannot sign in after the initial admin group is changed or left empty	The initial admin identity or group is empty, misspelled or does not match the value the token carries, so no account has policy rights	Keep a recovery admin identity documented and tested, correct the initial admin value, and restart NiFi so the authorizer is rebuilt

How much does Microsoft Entra ID single sign-on for NiFi cost and take?

What drives the effort of NiFi single sign-on with Microsoft Entra ID?

The effort follows the number of NiFi nodes and endpoints, how many Entra ID applications already exist, how groups are designed, whether you choose OpenID Connect or SAML, and how many policy groups NiFi must map to. A single-node test instance with one protocol and a small group set is far less work than a clustered production deployment with several group-based policy tiers. Each node must trust the same identity configuration, so a larger cluster adds verification steps rather than new design work. Ask the partner to break the scope down along these five factors so you can see which ones move the price.

What do we need to provide before the work starts?

You need a Microsoft Entra ID tenant administrator who can register the application, configure claims and assign groups, a NiFi administrator who can change nifi.properties and authorizer settings on every node, and a named test population of users who will sign in during verification. You also need an agreed change window, because switching the login method can lock out operators if it goes wrong. Confirm with the tenant's licensing contact or with Microsoft which Entra ID edition and features your group claims and conditional access rules depend on, since those requirements belong to your tenant and not to NiFi.

Can an internal team set up NiFi single sign-on with Entra ID alone?

Yes, an internal team can often do this alone when it follows one documented path, such as OpenID Connect with a single application registration and one claim for identity. The work is manageable for engineers who already run NiFi and administer Entra ID. The first step should be proving that a recovery administrator can sign in through a non-SSO method, such as a single-user or certificate-based admin, before the SSO change is made. Teams that split SAML and OIDC decisions, or that need custom group claim handling, usually find that the verification and rollback steps take more time than the configuration itself.

What recurring work comes after NiFi single sign-on goes live?

Recurring work includes renewing the certificates used for SAML signing or TLS, rotating the OIDC client secret when your policy requires it, and maintaining groups as people join, move or leave teams. Each NiFi upgrade may also change how the authentication provider or authorizer behaves, so the sign-in path needs to be retested after each upgrade. Plan these as operational tasks with owners and dates, and confirm with your identity team how Entra ID secret and certificate expiry alerts reach them. Ongoing support can be handled internally or through a retainer, depending on how much change you expect.

What should a written scope for NiFi Entra ID single sign-on include?

A written scope should name the protocol (OpenID Connect or SAML), the NiFi version and cluster topology, the Entra ID application registrations to be created, the identity claim and group claim design, the identity mapping rules, and the policy groups that will be granted access. It should list the test population, the verification steps, the recovery admin test, the rollback plan and the change window. It should also state who holds the tenant and NiFi administrator roles, what documentation is delivered, and what happens to any gaps found during testing. Ask for each item to be listed as a deliverable with an acceptance check.

Which Microsoft licensing or tenant requirements affect this work?

Licensing and tenant requirements depend on your Microsoft agreement, the Entra ID edition you hold, and whether you use features such as conditional access or group-based assignment. DeployOpen does not set these requirements and does not give licensing advice for Microsoft products. Ask your Microsoft account team or your tenant's licensing contact to confirm, in writing, which features your group claims and application assignments need before the scope is signed. Also confirm whether your organization uses Active Directory with Microsoft Entra Connect, because that changes where group membership is maintained.

How is the quote for NiFi Entra ID single sign-on produced?

DeployOpen does not publish a price list. A quote follows from a written scope that names the protocol, the number of NiFi nodes, the existing Entra ID estate, the group design, the number of policy groups and the testing and handover deliverables. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. If you expect changes after go-live, ask whether ongoing support is quoted separately as a retainer, and what is included in it.

How DeployOpen works on this

DeployOpen scopes NiFi sign-in with Microsoft Entra ID in writing before any configuration starts, then builds and tests it inside your own infrastructure. The work covers the app registration, the identity claim, group handling, identity mapping and a tested recovery admin path.

How we scope

Confirm whether OpenID Connect or SAML fits your Entra ID tenant, NiFi version and client policies
Record the identity claim, group claim source and expected group count in the written scope
Agree which NiFi nodes, URLs and environments are in scope before work begins

How we build

Register the NiFi application in Entra ID with redirect URIs that match your NiFi hostnames
Configure identity mapping rules and group-to-policy assignments tested against sample test accounts
Verify login, logout and token refresh behavior on every node in a non-production cluster first

How we hand over

Deliver configuration files, mapping rules and a record of the app registration settings used
Document the recovery admin account, where its credentials are held and how it is tested
Walk your administrators through group changes, access reviews and the rollback steps

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first
Ongoing support, upgrades and re-testing after Entra ID or NiFi changes are available as a retainer
Ask us to confirm the support boundaries and response expectations in the written quote

Apache NiFi single sign-on with Microsoft Entra ID