On Tue, Mar 28, 2017 at 04:18:24PM +0200, Jakub Hrozek wrote:
On Tue, Mar 14, 2017 at 06:25:39AM -0400, Simo Sorce wrote:
On Mon, 2017-03-06 at 14:49 +0100, Jakub Hrozek wrote:
[sssd]
domains = appdomain.test, posixdomain.test services = ifp, pam, nss [pam] application_services = sss_test [ifp] user_attributes = +phone [domain/appdomain.test] id_provider = ldap ldap_uri = ldap://server.test domain_type = application ldap_user_extra_attrs = phone:telephoneNumber [domain/posixdomain.test] id_provider = ldap ldap_uri = ldap://server.test
Jakub, I am thinking we may want to make some things here slightly different.
Sorry for not replying sooner, I just wanted to get the first KCM implementation to master before focusing on this.
I actually implemented most of your suggestions and opened a PR: https://github.com/SSSD/sssd/pull/215
Individual comments inline
Instead of calling them all domains, and having to sort out the differences later, I am thinking we may want to define a completely new section type called "application", this will allow us to "inherit" configuration from domain for compactness when both posix and non-posix are needed from the same domain.
Example:
[sssd] domains = domain.test services = ifp, pam, nss
[pam] application_services = sss_test
[ifp] user_attributes = +phone
[domain/domain.test] id_provider = ldap ldap_uri = ldap://server.test
[application/domain.test] inherit_from = domain/domain.test ldap_user_extra_attrs = phone:telephoneNumber
This is how it's implemented now
The idea is that the application domain inherits most of its parameters from the posix domain references (if any is referenced). If no difference between application domain and posix domain is needed then the application domain section could be almost completely empty (win).
Yes, I agree it's better.
I am not sure if we need to explicitly list application domains in the sssd or PAM sections, or if we should just automatically have them available by the simple fact they have been defined. One thing we may want though is to have an option that explicitly maps application domains to specific "services", for both PAM and IFP at the same time (given it makes no sense to do that independently and both need to be on the same page for this).
I didn't do this, mainly because it's IMO still beneficial for the admin to set the order between the POSIX and the non-POSIX domain manually. And I would prefer to enable 'auto-enablement' of domains in some systematic way, for all domains, not just the non-POSIX ones.
So move to a new section and modify the application_services parameter to take tuples: [applications] application_services = apache:domain.test myapp:other.dom \ otherapp:domain.test,other.dom,third.dom \ fooapp:ALL
This would work for PAM services, but only for PAM services. For the IFP clients, we still just look at the UID to check who's allowed to contact the IFP responder. Therefore I think it's even less confusing to keep the option in the PAM section.
The other option may be to list what services each application domain will be made available to in the application domain definition itself:
[application/domain.test] available_for = ALL
[application/other.dom] available_for = apache, otherapp, fooapp
[application/third.dom] available_for = otherapp
I think the problem will be to find the right balance to make it simple to configure which apps can get to which domains, the main trick being that we should not make application domains available to things like ssh, gdm, login by default because then NSS would fail later on and we'd waste time.
Yes, this is exactly how it's implemented now.
Also we need to be careful in never attempting double authentication (both to the posix domain and then again via application domain for any single app, as we may cause premature account locks that way). So perhaps explicitly listing services is always needed after all, and when a service is listed then only the specific list of application domains is considered for that service and nothing else.
Right, only the app services can contact the app domains and not the posix domains. And conversely, non-app-services can only contact the posix domains.
Just a few ideas to be able to better control what app does what. I am not sure we need different query types in the protocol either, because the above configuration will make it pretty clear what apps should get from the IFP, and backends will be of the appropriate type already so when you contact one they already know what they should return in their cache.
Thanks for these.
FYI, I updated the design page to reflect the implementation. I hope the design page can now be used by users and downstream consumers to learn about the feature: https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html