#561 [RFE] Add support for certificate-based authentication to directory servers
Opened 8 years ago by nalin. Modified 2 years ago

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)

2 years ago

Login to comment on this ticket.

Metadata