Improve plugin communication in validate/check and validate/triggerchallenge

[cornelinux]

We can improve the communition with the client plugins. We should improve the REST response values, so that the client plugins can more easily react.

Currently the response looks like this:

"multi_challenge": [
            {
                "attributes": null,
                "message": "please enter otp: ",
                "serial": "OATH11049691",
                "transaction_id": "05120102960518506577",
                "type": "hotp"
            },
            {
                "attributes": null,
                "message": "please enter otp: ",
                "serial": "OATH1105052A",
                "transaction_id": "05120102960518506577",
                "type": "hotp"
            }
        ],

The "attributes" section can contain additional, tokenspecific information like challenges of U2F or WebAuthn.

However, there can be additional information in each element of the multi_challenge section.

This could be:

Image

A key image can contain the challenge data in an image. This is e.g. similar to the TiQR token, which currently contains the img tag in the attribute sub section.

However, if we have a general image key, then we could display images of any kind. We could even display an image of the token, so that the user "knows" what to do - like accepting the challenge of the push token on his smartphone.

Or the image could be used to even enroll a token during the authentication process.

Client mode

There are different modes how a plugin would react in general. A key client_mode could tell the plugin the way it should react. This way, the plugin does not need the logic to decide based on the tokentype how to react. Thus we can add new token types, and if they use an existing mode, there would be no need to enhance the plugins.

Possible modes:

The mode otp would be the default mode. It tells the plugin, that is should display an entry field, where the user is supposed to enter something and press enter. The plugin will then send actively this credential to the /validate/check endpoint.

The mode poll tells the plugin, that it needs to poll the privacyIDEA server for the state of the given transaction_id. This mode would not require to display an input field.

Example

A resulting response could look like this:

"multi_challenge": [
            {
                "attributes": null,
                "message": "please confirm on your smartphone ",
                "serial": "PUSH11049691",
                "transaction_id": "05120102960518506577",
                "type": "push",
                "client_mode": "poll",
                "image": "data,...."
            },
            {
                "attributes": null,
                "message": "please enter otp: ",
                "serial": "OATH1105052A",
                "transaction_id": "05120102960518506577",
                "type": "hotp",
                "client_mode": "otp",
                "image": "data,...."
            }
        ],

TODO

• [x] implement client mode
• [x] implement image
• [x] result->authentication: [ ACCEPT, REJECT, CHALLENGE ]
• [x] add "preferred client_mode" in response (#3044)
• [ ] remove the last token from the top-level details (see https://github.com/privacyidea/privacyidea/blob/master/privacyidea/lib/token.py#L2114) (MS 4.0)
• [ ] remove "img" from attributes (MS 4.0)
• [ ] rename "multi_challenge" to "challenges". (MS 4.0)

[cornelinux]

Also check #2510

[cornelinux]

@nilsbehlen I would start implementing this on the server side:

• key client_mode with the possible values:
  • interactive (would be used for OTP tokens, Email, SMS)
  • poll (would be used for push tokens)
  • webauthn for Webauthn / FIDO2 tokens
  • u2f for U2F / FIDO tokens

Is there any other value you can think of?

• key image that simply contains a dataimage that the client can generically display.

[nilsbehlen]

webauthn for webauthn

[cornelinux]

@nilsbehlen Thanks, would it be the same process like u2f? Should be call this "fido" or is "webauthn" or "fido2" specific enough for the clients?

[cornelinux]

Conceptual Thought:

In the tokenclasses we can have a class constant that defines the client_mode setting value per class. Or can the client_mode differ for a certain token type? I do not think so.

[nilsbehlen]

i think we need to differentiate between u2f and webauthn so each has their own mode. I would prefer these names because they are more commonly used than the specification names.

[nilsbehlen]

TODO

Maybe you can also remove the challenges for u2f and webauthn from the detail.attribute field since they are already in the challenges themselves.

[cornelinux]

@nilsbehlen Do you remember, what "preferred client mode" is?

[nilsbehlen]

@nilsbehlen Do you remember, what "preferred client mode" is?

We have this implemented in multiple plugins. You can set your preffered token type in the settings and if a token of that type is triggered, the plugin starts in that mode. i.e. prompting for webauthn directly without having to press the button.