Hello,
On Tue, Aug 2, 2022 at 8:46 PM Dominik George <nik(a)naturalnet.de> wrote:
Hi,
during my evaluations and researches around implementing user and
device management using OAuth and OIDC, I also caught up on the
details of:
* sssd's architecture [1]
* Freedesktop's AccountsService [2]
* the idea making sssd implement AccountsService [3]
Currently, I am evaluating whether I should add an OIDC module to
sssd, or write my own authentication daemon handling it (mimicing sssd
to some extent). I will probably get back to the pros and cons around
this later in a separate thread.
One question though that I did not find an answer to, which is
somewhat important for both approaches, is:
Why does sssd implement its own wire protocol between client
libraries and responders, instead of using the D-Bus system bus?
I'd say, (one of the) main reason(s): to minimize a set of dependencies
pulled into random applications using SSSD client libraries (often
implicitly, thru, for example, glibc).
Security considerations are also important, especially when we talk about
PAM and system bus.
There are, perhaps, other reasons, but I think even those two are enough.
Actually, designing a draft for my own authentication daemon, I
decided to go with my own wire protocol (based on protobuf) as well,
and then thought that if I was going to implement a realmd provider
later on, I'd have to talk D-Bus anyway, so I could just as well use
it everywhere.
Since sssd decided to not do that, I assume there is a reason, so:
If I were designing a system like sssd, why should I not use D-Bus
to communicate between my PAM module and my backend daemon?
Disclaimer: I am not seeking to replace sssd; right now, all of this
is of purely academic nature, to understand the whole picture.
Cheers,
Nik
[1]
https://sssd.io/docs/architecture.html
[2]
https://www.freedesktop.org/wiki/Software/AccountsService/
[3]
https://docs.pagure.org/sssd.sssd/design_pages/accounts_service.html
_______________________________________________
sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahoste...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure