#561 [RFE] Add support for certificate-based authentication to directory servers
Closed: wontfix 4 months ago by pbrezina. Opened 9 years ago by nalin.

When negotiating encryption using either StartTLS or during the initial setup of an LDAPS connection, the client may be offered the opportunity to offer up its own certificate in order to authenticate to the directory server as part of the handshake.

Some servers will allow the client to subsequently "authenticate" using SASL/EXTERNAL and then proceed as an authenticated client. Since we support SASL/GSSAPI and simple binds, we should probably add the necessary plumbing to let SSSD authenticate this way, too.


Fields changed

component: SSSD => LDAP Provider

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.6.0
version: => 1.2.1

Fields changed

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

To clarify, this is something along the lines of using the client system's certificate and private key to authenticate as part of the TLS or SSL handshake. SASL/EXTERNAL should (hopefully?) be available as an option to instruct the server to authorize the client to use the directory based on naming information present in the client certificate (by mapping the subject DN to an entry in the directory, or by pulling out a subjectAltName value and using that, or something else).

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

Fields changed

feature_milestone: =>
proposed_priority: => Important

Fields changed

priority: minor => critical

Fields changed

milestone: SSSD Deferred => SSSD 1.10.0

Fields changed

proposed_priority: Important => Core

Hmm, at least some of this appears to have been done as part of ticket #780.

SSSD may need to be able to diagnose cases where the client's certificate is no longer valid, or at least have someone else (e.g., certmonger) watching out for that eventuality.

In at least some cases, the system which is running the directory server that SSSD is contacting will also be running a CA provided by the directory server's vendor. While certmonger can already handle that when the directory server and CA are IPA, SSSD also runs in other environments. We're going to teach certmonger to [talk to standalone Dogtag instances], and also look at teaching it to https://fedorahosted.org/certmonger/ticket/11 talk to ADCS. You may want to make use of that capability if/when it becomes available.

I don't know if that means a new ticket of some sort for SSSD, so I'm just making a note here so it won't come as a complete surprise later.

Fields changed

rhbz: 0 => todo
summary: Add support for certificate-based authentication to directory servers => [RFE] Add support for certificate-based authentication to directory servers

Cleaning the 1.10 milestones before putting tickets into it.

milestone: SSSD 1.10.0 => Temp milestone

Moving planned features and bug fixes into the 1.10 bucket.

milestone: Temp milestone => SSSD 1.10.0

Fields changed

milestone: SSSD 1.10.0 => Temp milestone

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: Temp milestone => SSSD 1.10 beta

Fields changed

design: =>
design_review: => 0
fedora_test_page: =>
selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Fields changed

priority: critical => minor

Fields changed

mark: => 0

Fields changed

changelog: =>
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
review: => 0

Mass-moving tickets not planned for the next two releases.

Please reply with a comment if you disagree about the move..

milestone: SSSD 1.13 backlog => SSSD 1.15 beta

Metadata Update from @nalin:
- Issue set to the milestone: SSSD Future releases (no date set yet)

3 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

4 months 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)

4 months 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/1603

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