#175 SSSD info plugin doesn't play nice with pam service
Opened 3 years ago by rcritten. Modified 2 years ago

If the pam auth module is enabled then infosssd is bypassed and no attributes are provided for the user. We should at least warn when this configuration is used.


Need to validate that any authentication used is an Apache-level plugin so that REMOTE_USER is set already and that mod_lookup_identity has set its variables.

Fields changed

milestone: => 1.2

Fields changed

owner: => jdennis
status: new => assigned

There is a good chance this is mostly resolved by the work done for ticket #191 if I'm understanding this ticket correctly. The problem is when authentication is performed by an external login the info providers are not run because they were only being run by Ipsilon auth providers. Ticket #191 fixed this (provided is is what this ticket is referring to). To get the info attributes one needs access to the info providers which is done this way in saml2idp.py

        self.info = provider._root.login.info

Then one only needs to assure that initialize_login_session() is invoked passing self.info, depending on how authpam is written initialize_login_session() might be invoked by a parent class method, otherwise you might have to explicitly invoke it.

I looked at the code and as far as I can tell authpam should populate the info attributes. Maybe I'm not understanding what the issue is. Is this only a problem with authform and not authpam?

The original problem description wasn't entirely clear to me, now that I've debugged it it makes sense but for those that follow I'm going to clarify what the problem is:

The problem isn't that authpam can't populate info attributes, it can (infoldap works just fine), it's combination of infosssd and pam which is the problem. infosssd relies on mod_lookup_identity to populate the user attributes, but that only runs if authentication is performed by Apache and REMOTE_USER is set.

Some of Ipsilon's authentication providers run in Apache (e.g. authform, saml, krb) and some run in Ipsilon (e.g. pam). Any authentication provider which does it work inside Ipsilon instea of Apache will not work with infosssd because mod_lookup_identity will not have run before the request arrives at Ipsilon. This is an architectural problem in the design of Ipsilon. I do not know of any way to solve this except by adding a new info provider that uses dbus in the same manner that mod_lookup_identity does. Adding a new SSSD info provider based on DBus is outside the scope of this ticket.

The original problem report suggests issuing a warning on this configuration. I'm not sure where that warning would be issued, by ipsilon_server_install? It's not clear to me that is the right place, nor would it be simple to explain which combination won't work (are there other auth providers which do their work inside Ipsilon instead of Apache?). If you enable other info providers you'll get attributes when using PAM, but then how do you explain what attributes you'll get and won't get?

I'm inclined to call this a documentation bug because it needs a lot of explanation.

Maybe we also need a new bug opened to create an info provider that calls SSSD via DBus.

If it's satisfactory to simply emit a message from ipsilon-server-install like this:

You have enabled PAM authentication and the SSSD info provider,
SSSD cannot provide user attributes if a user authenticates with PAM,
however other info providers will work in conjunction with PAM.

If that's not sufficient to close this ticket then I suggest we move this ticket to another milestone because this is more complex.

My understanding of the architectural design of Ipsilon is that Ipsilon depends on Apache to perform authentication. But authpam is an exception to this design. I'm not sure if we have other exceptions as well because I'm not that familiar with some of the other authentication providers and how they are implemented. But if we've violated the design goal of having Apache perform authentication then we've invited the exact problem seen here, we've got an architectural problem.

But my real question is why do we even have authpam in the first place when we've got authform which to my understanding is architecturally consistent and also uses PAM.

I believe the authldap provider also runs after the fact so it too wouldn't be able to leverage SSSD.

As for why authpam I'm not sure.

Well, my take is there is no simple solution to this then. The whole point of SSSD providing attributes via mod_lookup_identity is that authentication occurs in Apache and that is what we've been preaching for web apps. However, I realize Ispilon is a bit of an odd duck, it's not the traditional web app we've targeted with this advice.

Relying on mod_lookup_identity in Ipsilon to provide attributes just isn't going to work reliably since it's tied to the authentication implementation. Since Ipsilon offers a variety of authentication implementations (note that is not the same as variety of authentication mechanisms) it's inevitable we'll end up with a matrix of what authentication implementation works with a given info provider. Personally I think that is too complex and will make Ipsilon hard to use. I've seen this matrix problem in RADIUS between password format and auth mechanisms and it's been a source of endless confusion for admins because they don't want to grok all the intricacies of the underlying technology, nor should they. Ipsilon should be easy to set up and use, we should try to avoid nasty combinations that need a lot of explanation.

I think we should move infosssd to use the D-Bus API rather than mod_lookup_identity.
Since John is too busy, I'll pick this up and fix it for 1.3.

milestone: 1.2 => 1.3
owner: jdennis => puiterwijk
status: assigned => accepted

Metadata Update from @puiterwijk:
- Issue assigned to puiterwijk
- Issue set to the milestone: 1.3

2 years ago

Login to comment on this ticket.

Metadata