Hi,
last week, me, some other SSSD developers and Robbie looked at how the KCM
server in its current state can be debugged and what the current issues are.
One thing that stood out was that because every Kerberos operation now requires
a round-trip between libkrb5 to sssd-kcm and then to sssd-secrets via the REST
API, there are several components involved which makes the setup brittle. In
addition, the marshalling of each request into JSON and sending it over the
sssd-secrets REST API adds a bit of an overhead.
In a follow-up e-mail thread, Simo suggested that instead of using the REST
API, sssd-kcm might access the sssd-secrets database directly. I wanted to
discuss this potential change with the other developers.
As I’ve been thinking about Simo’s proposal, it actually makes sense to me. The
pros and cons as I see them are:
[+] less complexity. We would get rid of the whole JSON marshalling
code and wouldn’t have to allow on a second socket-activated deamon.
[+] better performance. Again, no JSON marshalling, but in the past we
were working around the REST API not providing a PATCH verb, so KCM had to
serialize requests to make sure two concurrent PUT requests don’t step over
one another.
[+] the “proprietary” API between KCM and secrets could be augmented
more easily to allow e.g. introspection and quota management better.
We wanted to allow some form of introspection and if we confine
ourselves to the REST API, I can’t think of another way of answering “how much
of their quota is UID X using" except adding a KCM-specific REST API endpoint
anyway.
[-] we would have to define a private API between secrets and KCM. The
REST API already has a nice router (or multiplexer if you will) to route the
different HTTP verbs into internal sssd-secrets actions, e.g HTTP GET into
retrieving a secret.
[-] overall allowing to write to the secrets database via the REST API
seems somewhat cleaner
Are there other opinions on the matter? Should we go ahead and change the
design to write to the database directly?
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
