From 7baff8db9185579e5137ed361dcdb2d89aed4ca8 Mon Sep 17 00:00:00 2001 From: Firstyear Date: Fri, 5 Mar 2021 11:49:34 +1000 Subject: [PATCH] Add cred display design (#367) --- designs/credential-display.rst | 53 ++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 designs/credential-display.rst diff --git a/designs/credential-display.rst b/designs/credential-display.rst new file mode 100644 index 000000000..d78e998d9 --- /dev/null +++ b/designs/credential-display.rst @@ -0,0 +1,53 @@ + +Credential Display UI +--------------------- + +We need a way to display the credentials associated to a user, that may be in a variety +of formats. We need to ensure that: + +* Credential disclosure is not possible in any form. +* Multiple classes and types of credentials are supported. +* That the displayed information matches what is configured for other commands to consume. + + +Draft Display (CLI) +------------------- + +An example of this display for the CLI: + +:: + + kanidm account credential list [-D account] + - account_metadata + locked: true|false + valid_from: + expire_at: + + - + type: Password|APIKey|PasswordMFA + locked: true|false + valid_from: + expire_at: + password: + totp: enabled|disabled + webauthn: + - token_name + - token_name + recovery_codes: enabled|disabled + + - + ... + +API +--- + +This would require a new api that goes via the IDM gateway to ensure that on the server side we +perform the correct transforms over the credential types to prevent data leaks. + +The ability to view credentials is bound by the standard search access control rules. + +The API would return a list of credential details, which is an enum of the possible classes supported +by the server. This ensures during addition of new credetial types or changes we update these protocol +types. + +This also helps to support future webui elements for credentials.