New issue
Advanced search Search tips

Issue 826417 link

Starred by 1 user

Issue metadata

Status: Started
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature

Blocking:
issue 791559



Sign in to add a comment

Smart card sign-in support in browser

Project Member Reported by emaxx@chromium.org, Mar 27 2018

Issue description

This bug tracks the work that has to be done on the Chrome browser side in order to support the smart card enterprise user sign-in in Chrome OS (launch bug 791559).

Design Doc: go/extended-login-smart-cards
 

Comment 1 by emaxx@chromium.org, Mar 28 2018

Blocking: 791559
Project Member

Comment 2 by bugdroid1@chromium.org, Apr 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/266cee1c518dfa07bbf3e58c100a39332adfa039

commit 266cee1c518dfa07bbf3e58c100a39332adfa039
Author: Maksim Ivanov <emaxx@chromium.org>
Date: Wed Apr 11 04:07:31 2018

Add type for challenge-response user key

* Create a class that holds the crypto key information;
* Store its instances in UserContext.

This is preparatory work for implementing the smart card sign-in in
Chrome OS. This CL alone is expected to bring no change of behavior.

Some more details for the context: This CL is part of effort for
allowing signing in via a cryptographic token (e.g. a smart card)
instead of a password. The actual secret passphrase (used for protecting
the local cached data) isn't shared with the browser anymore. Instead,
all structures related to the user's key in the browser memory and in
the D-Bus protocol are containing only the *public key information*.
When an authorization using such key takes place (e.g., when mounting
the user's cryptohome), the cryptohomed daemon will issue a challenge
request to the browser, and the browser has to respond with the
signature of the challenge.

Bug: 826417
Test: existing tests
Change-Id: I580285c860f0018442d957b7b2d8e44e78b5353b
Reviewed-on: https://chromium-review.googlesource.com/980887
Reviewed-by: Alexander Alekseev <alemate@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549752}
[modify] https://crrev.com/266cee1c518dfa07bbf3e58c100a39332adfa039/chromeos/BUILD.gn
[add] https://crrev.com/266cee1c518dfa07bbf3e58c100a39332adfa039/chromeos/login/auth/challenge_response_key.cc
[add] https://crrev.com/266cee1c518dfa07bbf3e58c100a39332adfa039/chromeos/login/auth/challenge_response_key.h
[modify] https://crrev.com/266cee1c518dfa07bbf3e58c100a39332adfa039/chromeos/login/auth/user_context.cc
[modify] https://crrev.com/266cee1c518dfa07bbf3e58c100a39332adfa039/chromeos/login/auth/user_context.h

Project Member

Comment 3 by bugdroid1@chromium.org, Apr 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3f610510ee579df6613dd5ad3528d2f56bb5ee27

commit 3f610510ee579df6613dd5ad3528d2f56bb5ee27
Author: Maksim Ivanov <emaxx@chromium.org>
Date: Wed Apr 11 09:39:12 2018

Add factory method for KeyDefinition

In preparation for the addition of challenge-response key type,
transform the existing non-special constructor of KeyDefinition into a
factory method. This should help to make the code more readable after
the challenge-response key type is introduced
(https://crrev.com/c/1000492): having two named factory methods is
cleaner than having constructor(s) with many arguments.

This CL is expected to bring no change of behavior.

TBR=bauerb@chromium.org (mechanical change after the API)

Bug: 826417
Test: existing tests
Change-Id: Ie1b5238b05bb112a7161e3cd75389293a932ceac
Reviewed-on: https://chromium-review.googlesource.com/1005335
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549841}
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chrome/browser/chromeos/login/auth/cryptohome_authenticator_unittest.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chrome/browser/chromeos/login/easy_unlock/easy_unlock_create_keys_operation.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chrome/browser/chromeos/login/existing_user_controller.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chrome/browser/chromeos/login/supervised/supervised_user_creation_controller_new.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chrome/browser/chromeos/login/supervised/supervised_user_login_flow.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chrome/browser/chromeos/policy/pre_signin_policy_fetcher_unittest.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chrome/browser/supervised_user/chromeos/manager_password_service.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chromeos/cryptohome/cryptohome_parameters.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chromeos/cryptohome/cryptohome_parameters.h
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chromeos/cryptohome/cryptohome_util.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chromeos/cryptohome/cryptohome_util_unittest.cc
[modify] https://crrev.com/3f610510ee579df6613dd5ad3528d2f56bb5ee27/chromeos/login/auth/cryptohome_authenticator.cc

Project Member

Comment 4 by bugdroid1@chromium.org, Apr 13 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ce6139c5e0c01c5e73d858b64c64819d3cc15973

commit ce6139c5e0c01c5e73d858b64c64819d3cc15973
Author: Maksim Ivanov <emaxx@chromium.org>
Date: Fri Apr 13 12:51:19 2018

Add challenge-response user key into KeyDefinition

* Store the challenge-response key information in KeyDefinition;
* Support the new challenge-response user key class in the to/from
  cryptohome protos conversion code.

This is preparatory work for implementing the smart card sign-in in
Chrome OS. This CL alone is expected to bring no change of behavior.

Some more details for the context: This CL is part of effort for
allowing signing in via a cryptographic token (e.g. a smart card)
instead of a password. The actual secret passphrase (used for protecting
the local cached data) isn't shared with the browser anymore. Instead,
all structures related to the user's key in the browser memory and in
the D-Bus protocol are containing only the *public key information*.
When an authorization using such key takes place (e.g., when mounting
the user's cryptohome), the cryptohomed daemon will issue a challenge
request to the browser, and the browser has to respond with the
signature of the challenge.

Bug: 826417
Test: chromeos_unittests --gtest_filter=CryptohomeUtilTest*
Change-Id: I7ef230a8f9829ffd88e4489338ff84d91466de31
Reviewed-on: https://chromium-review.googlesource.com/1000492
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550601}
[modify] https://crrev.com/ce6139c5e0c01c5e73d858b64c64819d3cc15973/chromeos/cryptohome/cryptohome_parameters.cc
[modify] https://crrev.com/ce6139c5e0c01c5e73d858b64c64819d3cc15973/chromeos/cryptohome/cryptohome_parameters.h
[modify] https://crrev.com/ce6139c5e0c01c5e73d858b64c64819d3cc15973/chromeos/cryptohome/cryptohome_util.cc
[modify] https://crrev.com/ce6139c5e0c01c5e73d858b64c64819d3cc15973/chromeos/cryptohome/cryptohome_util_unittest.cc

Project Member

Comment 5 by bugdroid1@chromium.org, Apr 17 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/53a2ac60356058866465b6d18f99f5ba5b8ac47a

commit 53a2ac60356058866465b6d18f99f5ba5b8ac47a
Author: Maksim Ivanov <emaxx@chromium.org>
Date: Tue Apr 17 11:15:30 2018

Add admin policy for cert-based SAML sign-in

The new policy gates the decision whether the client certificate based
user data protection should be used for users signing in via SAML. For
example, this allows to configure the smart card sign in, with the smart
card being the first factor of the user authentication.

* By default, the implementation-defined behavior will be used, which
  currently is a synonym to password-based authentication and cached
  data protection.
* When the "client certificate" type is configured via this policy, the
  client certificates chosen by a login app and the corresponding keys
  are used for authenticating users and protecting the cached data.

Bug: 826417
Test: unit_tests --gtest_filter=DeviceSettingsProviderTest.SamlLoginAuthenticationType

Change-Id: I634d39f6b7f14457d292d9ce88eeb458a7e28014
Reviewed-on: https://chromium-review.googlesource.com/983960
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Reviewed-by: Drew Wilson <atwilson@chromium.org>
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551294}
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/chrome/browser/chromeos/policy/device_policy_decoder_chromeos.cc
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/chrome/browser/chromeos/settings/device_settings_provider.cc
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/chrome/browser/chromeos/settings/device_settings_provider_unittest.cc
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/chrome/test/data/policy/policy_test_cases.json
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/chromeos/settings/cros_settings_names.cc
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/chromeos/settings/cros_settings_names.h
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/components/policy/proto/chrome_device_policy.proto
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/components/policy/resources/policy_templates.json
[modify] https://crrev.com/53a2ac60356058866465b6d18f99f5ba5b8ac47a/tools/metrics/histograms/enums.xml

Project Member

Comment 6 by bugdroid1@chromium.org, Apr 17 2018

Labels: merge-merged-testbranch
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ce6139c5e0c01c5e73d858b64c64819d3cc15973

commit ce6139c5e0c01c5e73d858b64c64819d3cc15973
Author: Maksim Ivanov <emaxx@chromium.org>
Date: Fri Apr 13 12:51:19 2018

Add challenge-response user key into KeyDefinition

* Store the challenge-response key information in KeyDefinition;
* Support the new challenge-response user key class in the to/from
  cryptohome protos conversion code.

This is preparatory work for implementing the smart card sign-in in
Chrome OS. This CL alone is expected to bring no change of behavior.

Some more details for the context: This CL is part of effort for
allowing signing in via a cryptographic token (e.g. a smart card)
instead of a password. The actual secret passphrase (used for protecting
the local cached data) isn't shared with the browser anymore. Instead,
all structures related to the user's key in the browser memory and in
the D-Bus protocol are containing only the *public key information*.
When an authorization using such key takes place (e.g., when mounting
the user's cryptohome), the cryptohomed daemon will issue a challenge
request to the browser, and the browser has to respond with the
signature of the challenge.

Bug: 826417
Test: chromeos_unittests --gtest_filter=CryptohomeUtilTest*
Change-Id: I7ef230a8f9829ffd88e4489338ff84d91466de31
Reviewed-on: https://chromium-review.googlesource.com/1000492
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550601}
[modify] https://crrev.com/ce6139c5e0c01c5e73d858b64c64819d3cc15973/chromeos/cryptohome/cryptohome_parameters.cc
[modify] https://crrev.com/ce6139c5e0c01c5e73d858b64c64819d3cc15973/chromeos/cryptohome/cryptohome_parameters.h
[modify] https://crrev.com/ce6139c5e0c01c5e73d858b64c64819d3cc15973/chromeos/cryptohome/cryptohome_util.cc
[modify] https://crrev.com/ce6139c5e0c01c5e73d858b64c64819d3cc15973/chromeos/cryptohome/cryptohome_util_unittest.cc

Project Member

Comment 7 by bugdroid1@chromium.org, Jun 14 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/de3023f9c68ae8d43633f27a06a95133fc619909

commit de3023f9c68ae8d43633f27a06a95133fc619909
Author: Maksim Ivanov <emaxx@chromium.org>
Date: Thu Jun 14 09:21:59 2018

Don't ask password for smart card sign-ins

Add plumbing that allows to skip the "manual password entry"
logic when the smart card SAML sign-in is used. Without this,
the user would be asked to type their password at the end of
their HTTPS-client-certificate-based SAML sign-in.

For this, the gaia sign-in screen JS code will ask the C++ handler
whether the user is expected to have a password. In this CL, the
handler is just a stub. It will be replaced later with an actual
smart card sign-in logic, once it's implemented.

No changes in behavior are expected from this CL alone.

BUG=chromium:826417
TEST=none (existing tests)

Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I44012f02fade8823556bcf1200a122b0791d8292
Reviewed-on: https://chromium-review.googlesource.com/1097406
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567203}
[modify] https://crrev.com/de3023f9c68ae8d43633f27a06a95133fc619909/chrome/browser/resources/chromeos/login/screen_gaia_signin.js
[modify] https://crrev.com/de3023f9c68ae8d43633f27a06a95133fc619909/chrome/browser/resources/gaia_auth_host/authenticator.js
[modify] https://crrev.com/de3023f9c68ae8d43633f27a06a95133fc619909/chrome/browser/ui/webui/chromeos/login/gaia_screen_handler.cc
[modify] https://crrev.com/de3023f9c68ae8d43633f27a06a95133fc619909/chrome/browser/ui/webui/chromeos/login/gaia_screen_handler.h

Project Member

Comment 8 by bugdroid1@chromium.org, Jun 20 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/27efc9e942927478e052065a5b1e34f9266602f6

commit 27efc9e942927478e052065a5b1e34f9266602f6
Author: Maksim Ivanov <emaxx@chromium.org>
Date: Wed Jun 20 21:03:45 2018

Pass GAIA ID when determining on passwordless sign-in

Add passing of GAIA ID from the login screen JS code to the C++ handler,
in addition to passing the user e-mail. This will allow to build
AccountId instance for the user in question in a more reliable way.

This CL should bring no change of behavior - logic for the passwordless
("challenge-response") logins is yet to be implemented.

BUG=chromium:826417
TEST=existing tests (no change of behavior is introduced)

Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I64a29ba845543644626fb972129c0b6376c3de2b
Reviewed-on: https://chromium-review.googlesource.com/1107059
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Maksim Ivanov <emaxx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569011}
[modify] https://crrev.com/27efc9e942927478e052065a5b1e34f9266602f6/chrome/browser/resources/chromeos/login/screen_gaia_signin.js
[modify] https://crrev.com/27efc9e942927478e052065a5b1e34f9266602f6/chrome/browser/resources/gaia_auth_host/authenticator.js
[modify] https://crrev.com/27efc9e942927478e052065a5b1e34f9266602f6/chrome/browser/ui/webui/chromeos/login/gaia_screen_handler.cc
[modify] https://crrev.com/27efc9e942927478e052065a5b1e34f9266602f6/chrome/browser/ui/webui/chromeos/login/gaia_screen_handler.h

Sign in to add a comment