Hello, On Tue, Aug 2, 2022 at 8:46 PM Dominik George <n...@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@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@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.fedorahosted.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
