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. 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 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). 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). 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 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. 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. 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. Hope this makes sense and complements the design rather than disrupt it, it does complement it in my mind :-) Simo. _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
