#412 Split data provider sockets
Closed: wontfix 3 years ago by pbrezina. Opened 14 years ago by sgallagh.

This is a subtask of ticket #44

The problem

Right now, all backend communication travels through a single socket {{{PIPEPATH/private/sbus-dp_DOMAIN}}}
This will not work when dealing with domains that use a combination of first-party and third-party providers. For example:

[domain/token]
id_provider = ldap
auth_provider = otp

In our current setup, this would translate to a single pipe {{{PIPEPATH/private/sbus-dp_token}}}.

Furthermore, we only support launching a single process for a backend right now, where in the above case we would need to launch a separate process for the otp provider.

Proposal

Handle multiple pipes

We should extend the {{{RegisterService}}} method in the monitor. When the reply is sent back to the connecting data provider, it should include four new string parameters. One each for the id, auth, access and chpass provider sockets in the format {{{/var/lib/sss/pipes/private/sbus-dp_otp_auth}}}.

The backends should bind to each of these sockets as needed, if they are handling this provider type.

Handle multiple processes

Instead of a single {{{command}}} option for launching the backend, there should be individual {{{id_command}}}, {{{auth_command}}}, {{{access_command}}} and {{{chpass_command}}}. If this value is unspecified or empty, we should attempt to invoke {{{sssd_be}}} and load the library name in the {{{*_provider}}} option. If multiple providers are specified this way, we should only load a single {{{sssd_be}}} process.

If the {{{*_command}}} option contains a special-case entry (e.g. {{{donotlaunch}}}), it should not launch a new process (this would be useful for third-party backends that provide multiple provider types).

Example:

[domain/otp]
id_provider = ldap

auth_provider = otp
auth_command = /usr/libexec/sssd/sssd_otp --domain=otp --auth --chpass

chpass_provider = otp
auth_command = donotlaunch

Sorry, I do not really agree with this ticket.
Our interface to providers is from sssd_be, if we need to provide access from external code via dbus then I suggest we make a dbus plugin for sssd_be so that it exports the dbus interface for each provider.
This way you can still do things like using the internal ldap provider for identity and offload only the auth provider.

Deferring to 1.2. It's too soon to release a stable public API.

milestone: SSSD 1.1 => SSSD 1.2

Fields changed

milestone: SSSD 1.2 => SSSD 1.3

Fields changed

owner: sbose => sgallagh

Fields changed

priority: blocker => minor

Fields changed

milestone: SSSD 1.5.0 => SSSD 1.6.0

Fields changed

coverity: =>
milestone: SSSD 1.6.0 => SSSD 1.7.0
upgrade: => 0

Fields changed

milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Deferred
rhbz: =>

Fields changed

rhbz: => 0

Metadata Update from @sgallagh:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1454

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata