#3050 [RFE] Use one smartcard and certificate for authentication to distinct logon accounts
Closed: Fixed 2 years ago Opened 2 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.

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

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.

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.

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.

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

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.

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

Fields changed

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

Fields changed

priority: major => critical

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

2 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

2 years ago

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 set to the milestone: SSSD 1.15.2 (was: SSSD 1.15.1)

2 years ago

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

2 years ago

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
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

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
- Issue status updated to: Open (was: Closed)

2 years ago

Reopened; because it is still not fixed.

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

2 years ago

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 set to the milestone: SSSD 1.15.3 (was: SSSD 1.15.2)

2 years ago

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

2 years ago

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

2 years ago

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 status updated to: Closed (was: Open)

2 years ago

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

2 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

2 years ago

and openssl patch

master:

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)

2 years ago

Login to comment on this ticket.

Metadata