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.