Issue #3050: [RFE] Use one smartcard and certificate for authentication to distinct logon accounts - sssd

SSSD / sssd

#3050 [RFE] Use one smartcard and certificate for authentication to distinct logon accounts

Closed: Fixed 7 years ago Opened 8 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1340711

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

[RFE] Use one smartcard and certificate for authentication to distinct logon
accounts

This is a general use case that enables
the ability to use the same PIV (or other) credential (a
hardware key based PKI authenticator) to strongly authenticate (two-factor
authentication) multiple, distinct, user accounts on the same workstation, or
server, or Kerberos realm. The princpal effeciency is that a single strong
credential issued to individuals may be used to authenticate to various users
contexts, in other words user accounts, where the user contexts may be distinct
and isolated both laterally and in managing least elevated priviledge and
priviledge isolation within an individuals assigned user accounts.

The princpal benifit is the avoidance of issuing multiple PIV, Derived PIV, or
other two-factor PKI credentials for the sole purpose of managing least
elevated priviledge and priviledge isolation within an individuals assigned
user accounts.

The implemenation for this use case must be RFC 4556 "Public Key Crptography
for Initial Authentication in Kerberos (PKINIT)" conformant. The new feature is
to permit the user to select or enter an altertnate User Principal Name (UPN)
for a Kerberos PKINIT Ticket Granting Ticket (TGT), among an authorized list of
UPNs for the user, that securely binds the users PKI certificate in an
authentication to that specific user account.

jhrozek commented 8 years ago

Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
mark: no => 0
milestone: NEEDS_TRIAGE => SSSD 1.16 beta
review: True => 0
selected: =>
testsupdated: => 0

dpal commented 8 years ago

So is this the requirement to be able to select which account you want to login if you use the same cert for more than one account? Is the logic something like: user uses the card, server detects that there are more than one accounts mapped to this cert and returns the list, user chooses which account to use. Is this the expected workflow or something else? Or it is expected that user specifies the account he wants to login explicitly first?

I will leave the same comment in BZ.

jhrozek commented 8 years ago

I guess the username would have to be provided in one way or other, otherwise we can't know which user to map the cert to.

dpal commented 8 years ago

Replying to [comment:3 jhrozek]:

I guess the username would have to be provided in one way or other, otherwise we can't know which user to map the cert to.

This is understood. The question is more bout the user experience expectations. Is it is expected to always ask for name or to ask for name only when there is ambiguity? The answer to this questions will dictate the technical solution. I am just trying to clarify the requirement.

jhrozek commented 8 years ago

I haven't really thought about the prompting, but PAM has the ability to prompt for username as well via PAM_ECHO_ON.

cc: => sbose

sbose commented 8 years ago

Most of the login processes ask for a name independently of PAM anyway before calling pam_authenticate, mainly because one of the arguments to pam_start() is the user name.

Currently I only know of gdm which can run in a mode where it detects that a Smartcard is inserted and hands over control directly to PAM. SSSD currently expects that the lookup by certificate returns only one user in this case. Nevertheless it would be possible to enhance SSSD to instruct pam_sss to prompt for a user name in this case as well.

dpal commented 8 years ago

Right. The question whether it will always prompt or only in the case where it detected a duplicate and needs to disambiguate.

jhrozek commented 7 years ago

Fields changed

milestone: SSSD Future releases (no date set yet) => SSSD 1.15.1
owner: somebody => sbose

jhrozek commented 7 years ago

Fields changed

priority: major => critical

Metadata Update from @jhrozek:
- Issue assigned to sbose
- Issue set to the milestone: SSSD 1.15.1

7 years ago

jhrozek commented 7 years ago

Since we are releasing 1.15.1 today, I'm moving all unfinished tickets from 1.15.1 to 1.15.2

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue close_status updated to: None

7 years ago

lslebodn commented 7 years ago

master:

Metadata Update from @lslebodn:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

7 years ago

lslebodn commented 7 years ago

Reopened; because it is still not fixed.

7 years ago

jhrozek commented 7 years ago

The certmap library patches:
* c44728a
* 49f8ec8
* b341ee5
* 81c564a
* 70c0648
* 3994e87
* 31a6661
* db36dca
* 8b7548f
* 843bc50

7 years ago

jhrozek commented 7 years ago

python list method
* a0b1bfa
* 440797c

7 years ago

jhrozek commented 7 years ago

Additional fixes:
* 8284375
* 2cf7bec
* 415d931

7 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue close_status updated to: Fixed

7 years ago

lslebodn commented 7 years ago

and openssl patch

master:

Edited 7 years ago by lslebodn

Metadata Update from @lslebodn:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

7 years ago

pbrezina commented 4 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/4083

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.

Metadata

Assignee

sbose

Tags

None

Blocking

None

Depending on

None

Priority

critical

Milestone

SSSD 1.15.3

type

enhancement

component

SSSD

version

None

selected

None

testsupdated

false

patch

false

rhbz

https://bugzilla.redhat.com/show_bug.cgi?id=1340711

design_review

false

review

false

changelog

None

keywords

None

coverity

None

mark

false

blocking

None

design

None

sensitive

false

sbose

blockedby

None

feature_milestone

None

SSSD / sssd

Source Code

Documentation

#3050 [RFE] Use one smartcard and certificate for authentication to distinct logon accounts Closed: Fixed 7 years ago Opened 8 years ago by jhrozek.

Metadata

#3050 [RFE] Use one smartcard and certificate for authentication to distinct logon accounts

Closed: Fixed 7 years ago Opened 8 years ago by jhrozek.