RFD 155 - Scoped Webauthn Credentials

[Joerger]

This feature was initially suggested by @jentfoo in this discussion.

I intend to use this feature for admin actions to allow safe reuse of webauthn credentials for specific "bulk" admin actions:

• Creating a user - 1 MFA for CreateUser and 1 for CreateResetPasswordToken
• Updating a SAML Idp service provider - 1 MFA CreateSAMLIDP... to check existence, and 1 for UpdateSAMLIDP...
• Bulk creating of resources with tctl create
• Creating cloud invites with the button in the WebUI

[github-actions]

The PR changelog entry failed validation: Changelog entry not found in the PR body. Please add a "no-changelog" label to the PR, or changelog lines starting with changelog: followed by the changelog entries for the PR.

[jentfoo]

I appreciate the effort to minimize the scope of an MFA. However I think the tracked reuse complicates this:

• More writes to the backend as each use needs to be atomically decremented, that atomic nature now becoming very important to this update
• The client has no guarantees that reuse is exactly as intended anyways, instead this mostly provides an automatic expiration mechanism (based on usage)

As a possible simplification we could have a reuse boolean, which would not always be allowed (similar to how you currently define reuse is not always allowed). This flag would mean only MFA actions which don't allow reuse would require a single update to track. In other cases we would rely on short expiration, but in technically allow unlimited reuse during that period.

[Joerger]

I am ok with removing this, I just wanted to show it in case we had strong opinions to have it.

[codingllama]

Adding to this, we could have clients tell the server when they are done using a challenge, so it can be cleaned up. We may not even need the reuse bool, as some kinds can't be reused and others (like admin challenges) can use the client signal for the early delete.

[Joerger]

I'm going to omit this from the RFD, but I'll investigate this during implementation as a nice to have.

[codingllama]

Looks good, just waiting for resolution in a couple of open threads.

[jentfoo]

This looks like a great improvement, thank you for putting it together @Joerger

[codingllama]

LGTM.

[Joerger]

@rosstimothy does this RFD need approval from product, or should I remove those required reviewers?

[rosstimothy]

Curious, why do these need to be distinct scopes?

[codingllama]

My 2c: they don't have to be distinct, but I think it's a good distinction. The passwordless challenge is a tad more powerful than the login one, as it covers multiple factors at once. It also only happens in very specific situations (initial user login), whereas the SCOPE_LOGIN equivalent is used for re-authentication (pre RFD 155, that is).

[rosstimothy]

Like I said I was more curious why the two are distinct and not advocating for them to be unified. I'd be happy with a comment elaborating on the differences.

[Joerger]

It's not exactly necessary, but it comes out naturally in the code, replacing passwordless bool in many methods with just scope, and I see no reason to not have this scope.