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.