Web app authorization with FreeIPA groups via SSSD

How web apps can authorize by FreeIPA group without LDAP code

Several web applications on the same network often need group-based access, and each team is tempted to write its own LDAP queries to find out who belongs to which group. The documented alternative is to let SSSD's InfoPipe D-Bus interface, exposed on the client, feed mod_lookup_identity in Apache, so the application reads user attributes and group membership from the request environment instead of talking to the directory itself. The application then only checks group names it receives. The division of labor is simple. FreeIPA holds the users and groups, along with the policies that decide who belongs to them. SSSD on the Apache host reads that data through the InfoPipe interface (org.freedesktop.sssd.infopipe). mod_lookup_identity copies the attributes it is configured to expose into the Apache request environment. The application checks group names and makes its own access decision. The FreeIPA workshop example uses the user's email address as the attribute passed through this route, which shows the pattern without requiring any directory code in the app. Before you commit to this route, confirm three things in your own environment: that the web host is an enrolled IPA client with a working SSSD configuration, that the Apache module and SSSD InfoPipe interface are available for your distribution and versions, and that the attributes you need are actually exposed to the InfoPipe layer. Group names passed this way are only as trustworthy as the Apache side that sets them, so plan how headers or environment variables are stripped from incoming requests and who may change the Apache configuration.

What a FreeIPA group authorization setup requires

Group-based authorization for a web app depends on five things lining up before any configuration starts: the FreeIPA deployment, the Apache host enrolled as a client, SSSD exposing user data, the module that passes it to the app, and the groups that carry the access decisions. Confirm each one with your platform team before scheduling the build.

A working FreeIPA deployment

The web host needs a reachable FreeIPA domain with users and groups already defined in the directory. Confirm which replicas the host will query, that DNS resolves the IPA server names, and that the time sources are stable, since Kerberos-based login fails when clocks drift. Confirm the current FreeIPA version with your platform team before you pick client packages.

Apache host enrolled as an IPA client

The web server must be an enrolled FreeIPA client so that SSSD on that host can resolve the directory identities that Apache sees. Confirm that the host's enrollment, its host entry and its SSSD domain configuration are in place, and that the distribution you run is one your platform team supports for client enrollment.

SSSD with InfoPipe access

SSSD's InfoPipe interface exposes user attributes over D-Bus, and the service must be enabled and allowed to answer requests from the web server's context. Ask your platform team which SSSD version ships on your distribution, confirm the InfoPipe responder is present in that build, and test the D-Bus call before you configure Apache.

The mod_lookup_identity module

The Apache module reads identity data from SSSD and places attributes such as the user's email address into the request environment, which the application then reads. Confirm the exact package name for your distribution and the Apache version it targets. The FreeIPA workshop on web application authentication and authorisation describes the expected configuration.

Groups and users that drive access

Authorization by group only works when the groups reflect real access decisions, such as an application admin group or a finance reviewer group. Confirm the group names, who manages their membership, and whether nested groups are needed. Write the expected access matrix down before you configure the application, so testers can check each group against it.

TLS on the web front end

Group membership and user attributes travel from SSSD to the application through the web server, so the front end must serve traffic over TLS with a certificate your clients trust. Confirm who issues the certificate, whether it comes from the FreeIPA CA or another authority, and how renewal is handled before go-live.

How to configure InfoPipe and mod_lookup_identity in order

This sequence takes a web host from a bare Linux machine to an Apache location that receives FreeIPA user attributes and group membership in each request, so the application can authorize by group. Each step closes with a check you can run before moving on.

Enroll the web host as an IPA client
The web server team enrolls the host into the FreeIPA domain with the client installer, which configures SSSD, Kerberos and the host keytab. Confirm enrollment by running id for a known test user and seeing the expected group memberships, then run ipa host-show from an administrator session to confirm the host record exists. Do not continue until both checks return the groups you expect, because every later step depends on SSSD resolving identities on this host.
Enable the InfoPipe responder in SSSD
Add the infopipe responder to the services line in /etc/sssd/sssd.conf and define an [infopipe] section that names the attributes to expose, such as the mail attribute. Restart SSSD and confirm the service loads without errors in its logs. Check that the InfoPipe service appears on the system bus, because the next steps depend on it. Confirm exact option names against the SSSD man pages for your installed version.
Confirm the D-Bus service is reachable from Apache
Run the Apache worker as the account it uses in production and check that it can reach the system bus and call the InfoPipe interface, org.freedesktop.sssd.infopipe. A common failure is a service unit or SELinux policy that blocks the web process from the bus, so test under the real service context, not your administrator shell. The check passes when a D-Bus query returns the test user's attributes without an access error.
Install and configure mod_lookup_identity
Install the mod_lookup_identity module on the web host and load it in the Apache configuration. Map each chosen attribute, such as the user's email address and group list, to a request environment variable name that the application will read. Keep the mapping minimal so the application receives only what it needs. Validate the configuration with apachectl configtest and reload Apache only after the syntax check passes.
Restrict the Apache location to authenticated users
Protect the application path with an authentication method that establishes a verified remote user before mod_lookup_identity runs, such as Kerberos negotiation or another method your team has tested against FreeIPA. Add a require rule so anonymous requests are rejected. Confirm that an unauthenticated request to the protected path returns an authentication challenge or a denial, and that an authenticated test request reaches the application.
Verify attributes and groups in a test request
Send an authenticated request from a test account to a diagnostic page or a test endpoint that prints the request environment. Check that the email attribute and the group membership values arrive under the variable names you configured. Repeat with a second test user who belongs to different groups to confirm the values change per user. Do not expose this diagnostic endpoint in production.
Read group membership in the application
The application team reads the group variable from the request environment and maps group names to its own roles or permissions, without opening an LDAP connection. Test one allowed group and one denied group, and confirm the application grants and refuses access as designed. The sequence is complete when both users behave as their FreeIPA group memberships predict. Document which group names the application trusts, since a renamed group in FreeIPA changes access.

Which identity source to use for each kind of web app

Applications serving users on enrolled Linux or managed desktops can accept the Kerberos ticket the user already holds, so no password is typed and the application never receives one. This route fits internal tools used from enrolled workstations within one realm. Group checks still need a lookup step after the user is authenticated, and the service principal and keytab become credentials you must manage.

Best fit: internal tools used from enrolled workstations in a single FreeIPA realm.
Identity source: the authenticated principal comes from the KDC, but group data still needs to be read separately.
Browser and network reach: users must reach the application under a name that matches the service principal, and browser negotiation must be configured.
Off-domain users: contractors and unmanaged devices usually cannot use this route without a second sign-in path.
Key handling: keytab ownership, permissions and rotation become a recurring operational duty.

Before choosing this route, confirm which users and devices must sign in and whether each one can obtain tickets from the KDC. The sibling topic on Kerberos single sign-on for web applications covers the setup steps.

How FreeIPA groups and attributes map to request variables

This table shows how a FreeIPA user's login, email, group memberships and other attributes reach the Apache request environment through SSSD InfoPipe and mod_lookup_identity, and where your application makes the authorization decision. Read each row as a decision you make or a value you confirm in your own SSSD configuration before writing any route rules.

Identity item	Where it comes from	What you choose or confirm
Login name	FreeIPA user uid, read through SSSD InfoPipe	Confirm the exact attribute name returned in your environment and map it to a request variable name you will use in code
Email address	FreeIPA user mail attribute, exposed through InfoPipe	Choose the request variable name, for example a name that matches your app's user model, and confirm it is populated for every user who needs access
Group memberships	Direct and indirect FreeIPA group membership as resolved by SSSD	Decide which groups gate which routes and whether nested groups count, then test with a user from each group
Route to group mapping	Defined in your application or Apache configuration, not in FreeIPA	Write one rule per protected route and default to deny when no group matches
Attribute set in SSSD	The InfoPipe and identity lookup settings in your sssd.conf	Confirm which attributes SSSD exposes on each client before relying on them, because the set is controlled by your configuration
Service account access	The principal or account that reads identity data on the web host	Confirm the host can read InfoPipe data under your access policy and that no application code needs its own LDAP bind

Security settings that keep group checks trustworthy

Group-based authorization is only as sound as the path that delivers the group data to the application. The cards below cover who can read identity data on the web host, how the application knows the values came from Apache, and how group names and host access are kept under review.

Limit InfoPipe access to Apache

The SSSD InfoPipe D-Bus interface (org.freedesktop.sssd.infopipe) is the source of the attributes that mod_lookup_identity places into the request environment. Restrict which local accounts can reach that interface so that only the Apache service account reads identity data on the web host. Confirm the D-Bus policy and SSSD access-control settings for your SSSD version before go-live, and test that other local users are refused.

Trust only Apache-set values

The application should read identity values only from the environment that Apache populates after authentication. Configure Apache so that any header or variable a client sends with the same name is removed before mod_lookup_identity runs, and have the application ignore any identity field it did not receive from that path. Test with a forged header from an outside client to confirm it has no effect.

Keep group names stable

Authorization rules that match on group names break silently when a group is renamed, or when a similar name is reused for a different purpose. Agree a naming convention for groups used by applications, keep the mapping from group to application role in version control, and require a review before any group that grants access is renamed or deleted. Ask who in your organization owns that review.

Apply HBAC rules to the web host

Group membership decides what a user is allowed to do in the application, but HBAC rules decide who may log in to the web host at all. Create host-based access control rules that limit logins on the web server to the administrators and service staff who need them, and keep application users off the host itself. Verify the rules with a test account from a group that should be refused.

Treat the app as a read-only consumer

The application should query FreeIPA identity data but never write to it. Do not give the application a bind identity that can modify users, groups or policies, and do not let it create or change group membership from its own administration screens. Changes to who belongs to which group belong in FreeIPA, where they are audited and reviewed. Confirm that any LDAP bind the application uses is read-only.

Confirm settings per SSSD version

Access-control behavior for the InfoPipe interface and the D-Bus policy files can change between SSSD releases and packaging. Before relying on the design, record the SSSD and mod_lookup_identity versions on the web host, check the vendor or distribution documentation for those exact versions, and repeat the access tests after each upgrade. Treat an unexpected change in readable attributes as a failed check.

Why group-based authorization fails and how to fix it

This table lists the failures teams most often hit when apps read FreeIPA groups through SSSD InfoPipe and mod_lookup_identity, with the likely cause, the fix and the log to check for each. Work down the rows in order, since a missing SSSD responder or DNS problem hides every later symptom.

Symptom	Likely cause	Fix and where to check logs
Attributes arrive empty in the request environment	The InfoPipe responder is not listed in the SSSD services line, so the D-Bus interface has nothing to serve	Add infopipe to the services line in sssd.conf, restart SSSD and confirm the org.freedesktop.sssd.infopipe name is reachable. Check the SSSD logs under /var/log/sssd/ for responder startup errors.
Apache gets a D-Bus permission denial	The Apache worker user is not allowed by the D-Bus policy to call the InfoPipe methods	Grant the web server user read access to the InfoPipe bus interface through the D-Bus policy file, then reload the bus. Check the journal for D-Bus access denied messages and the Apache error log for mod_lookup_identity failures.
A user is missing a group that exists in FreeIPA	Nested or recently added membership has not yet been picked up by the SSSD cache, or the group is not in the scope the client resolves	Clear the SSSD cache for the user, confirm membership with id and getent group on the host, then retry. Check sssd_domain logs for lookup and cache refresh entries.
Users can set their own attributes by sending headers	Apache passes client-supplied headers with the same names as the lookup_identity variables, so the app trusts the copy the client sent	Unset or strip incoming headers with those names at the reverse proxy, and make the app read only values set by mod_lookup_identity. Check the access log and test with a crafted request from outside the proxy.
Lookups fail or time out on an unenrolled or misconfigured host	The host is not enrolled as an IPA client, or it cannot resolve IPA DNS records, so SSSD cannot reach the domain controllers	Confirm enrollment with ipa-client status, verify the resolver lists IPA DNS servers and test SRV record lookups for the domain. Check /var/log/sssd/ and the resolver settings in resolv.conf.

How to test group checks before users depend on them

Test the group checks before any user depends on them, and build the test plan around the decision the application makes: allow or deny based on group membership. Create at least one test account inside each FreeIPA group the application checks, one account outside all of them, and one account that belongs to a group the application must not honor. For each account, sign in through the real path (Apache with mod_lookup_identity in front of the application) and record what the application receives. Confirm that the attributes populated from SSSD's InfoPipe interface, such as the email address, arrive in the request environment with the names your code expects, and that the group values match what ipa user-show reports for that account.

Then check the denial paths. An account outside the permitted groups should receive the status your access design specifies, and the application should not fall back to a default role or an empty response that looks like success. Test a request with no session, a session for an account that has been disabled in FreeIPA, and a request that reaches the application without going through Apache, since that path can bypass the identity lookup entirely. Record each result so the expected status codes sit next to the test that produced them. Whether a disabled account is refused immediately or only after cached data expires depends on your SSSD settings and the application's session lifetime, so confirm that behavior in your own environment rather than assuming it.

Repeat the same tests after a group change and after SSSD's cache expires. Add a test account to a permitted group, wait for the cache to refresh or clear it on the host where Apache runs, and confirm access is granted. Remove the account and confirm access ends within the window your team has agreed to accept. Cache lifetimes, the sssd.conf settings that control them, and any session caching in the application are environment-specific, so write down the values you observe and treat them as the baseline for your change process. Keep these tests as a regression suite, because a later SSSD or Apache upgrade can change how attributes are passed.

Questions buyers ask before outsourcing group-based authorization

How much effort and time does group-based authorization through SSSD take?

The effort depends mostly on the number of applications, how much authorization logic each one needs beyond "is in group X," and how many identity systems are already in place. A single application that reads one attribute and checks one group is a small change. Several applications with nested groups, role mapping and different session rules add design and testing work for each one. No fixed duration is published here, so ask any partner to break the estimate into per-application work, shared SSSD and Apache setup, and testing. Confirm the timeline against your own environment and change process.

What drives the cost of this work up or down?

Four factors shape most of the cost:

The number of web applications and how each one reads identity data
Custom authorization logic, such as mapping groups to in-app roles or handling exceptions
The state of your existing authentication stack, including whether hosts are already enrolled and SSSD is already configured
The number of environments (test, staging, production) that need matching configuration

One-time costs cover design, configuration, and testing. Recurring costs appear when you add applications, change group structures, or upgrade components. Ask for these items to be listed separately in any quote.

Can our own team implement this without an outside partner?

Yes, if your team already runs FreeIPA, understands SSSD on Linux, and can administer Apache and its modules. The work is configuration rather than custom code, but errors in group design or access rules can expose data, so a dry run in a test environment is important. Teams without this experience usually spend more time on troubleshooting than on the build. An outside partner can take on the design and testing while your staff keep ownership of the running system.

What does the work need from our side before it starts?

Plan for these inputs:

Hosts enrolled in FreeIPA, with SSSD running and resolving users and groups correctly
A written group design that maps each application to the FreeIPA groups allowed to use it
Test accounts in each relevant group and at least one account outside every group for negative testing
Access to the web servers, the FreeIPA administrators who approve group changes, and a test environment that matches production

Without a clear group design, the authorization rules will be hard to audit later.

How does this differ from Keycloak federation with FreeIPA?

Group-based authorization through SSSD lets an application running on a host enrolled in FreeIPA read user attributes and group membership directly, and decide access in the web server or application. Keycloak federation places an identity provider in front of FreeIPA so applications receive OIDC or SAML tokens. The first suits applications on the same Linux estate that can use Apache modules. The second suits applications that need standard sign-in flows, token-based access, or access from outside your internal network. Many organizations need both, and the choice should follow each application's protocol support and where users sign in.

What security checks should we ask about before approving the design?

Ask how the design prevents authorization from being granted by an attribute the user can change, how the web server rejects requests when identity lookup fails, and how SSSD reads data from FreeIPA with the access it needs and no more. Confirm that TLS is used between components, that test cases cover users outside each group, and that logs record denied access. Ask for the findings in writing so your security team can review them and decide what to accept.

What does a fixed-scope quote cover for this work?

Most DeployOpen engagements are fixed-scope, so the agreed scope, deliverables and timeline are written down before work starts. For this topic, a quote should list the applications in scope, the group design and its review, the SSSD and Apache configuration on each host, the test cases and results, documentation for operators, and knowledge transfer to your team. It should also state what is excluded, such as application code changes or changes to FreeIPA policy outside the agreed groups. Ask for ongoing support and upgrades as a separate retainer if you want them.

How DeployOpen scopes and delivers FreeIPA group authorization

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For web application authorization through SSSD, we start from the groups your applications must check, then build and verify the attribute and group path on infrastructure you control.

How we scope

Inventory each web application, its authorization rules and the FreeIPA groups those rules depend on.
Confirm which SSSD host runs InfoPipe and which Apache front ends will run mod_lookup_identity.
Agree in writing which attributes, group checks and test accounts are covered before work starts.

How we build

Configure SSSD InfoPipe access and mod_lookup_identity on the agreed hosts, with settings recorded in version control.
Map FreeIPA groups to application roles and test denial paths for users outside each group.
Verify attribute and group lookups against nested groups, disabled accounts and users missing from the expected groups.

How we hand over

Deliver configuration, group-to-role mapping, test cases and results for the scoped applications.
Document operational steps for adding applications, changing group rules and rotating related credentials.
Walk your platform and application owners through the design, failure modes and checks they will repeat.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Re-test authorization paths when SSSD, Apache or FreeIPA versions change on your hosts.
Ask any partner, including us, to confirm support terms and upgrade responsibilities in the written scope.

Web application authorization with FreeIPA groups through SSSD