NAS-131396 / 25.04 / Add support for user-linked API keys #14578
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The primary motivation for converting API keys so that they are explicitly linked to user accounts is to provide some method for TrueNAS Connect to use tie in to local or directory services accounts to a credential that is persistently stored in the TrueNAS Connect keychain. The legacy API key mechanism was insufficient for this purpose because the mismatch between user accounts and API keys could lead to administrators retaining NAS access after account deletion, expiration, or locking. For more in-depth context and reasoning please refer to the internal design document NEP-053. For this purpose, this commit makes the following changes: 1. Legacy API keys are migrated to a user_identifier LEGACY_API_KEY which is automatically linked to the root, admin, or truenas_admin account depending on server configuration. 2. If the legacy API key granted less than FULL_CONTROL, then the API key is migrated with a `revoked` state so that the system administrator has an opportunity to review and generate a new key and/or service account that provides the correct level of access. 3. API key authentication now passes through libpam. 4. user.query results now include an `api_keys` key that contains a list of IDs for API keys that exist for the user. 5. Authenticated users with READONLY_ADMIN privilege or greater are able to create and manage their own API keys. During development of this new feature, it was determined that the original API keys were written with insufficient hashing rounds leading to the following changes: 6. On successful authentication the stored hash of any LEGACY_API_KEY is automatically upgraded to a newer sha512-based standard with significantly increased hashing rounds. 7. Dependency on the passlib library was removed. Since libpam is now used for all non-token authentication methods, a new auth login endpoint (auth.login_ex) was added to middleware to facilitate future enhancements for challenge-response authentication mechanisms. Authentication via username + password + OTP token has been converted to this new standard. This new endpoint is more closely aligned with standards and requirements in NIST SP 800-63B. In summary the following changes were made: 8. An AuthentationContext dataclass was created to house a middleware session's PAM context and associated information. An instance of this is stored in the session's App object. 9. A new endpoint auth.login_ex was added that is expandable and is aware of the server's configured "authentication assurance level". 10. Existing login endpoints (auth.login, auth.login_with_api_key, auth.login_with_token) were converted to wrappers around auth.login_ex. 11. Initial implementation of session lifetime and inactivity guidelines for different authentication assurance levels was added. 12. Challenge-response workflow for username + password + OTP token implemented with associated tests.
bugclerk
changed the title
mgrimesix
reviewed
Sep 25, 2024
mgrimesix
reviewed
Sep 25, 2024
| from middlewared.utils.auth import LEGACY_API_KEY_USERNAME | ||
| from middlewared.utils.crypto import generate_pbkdf2_512, generate_string | ||
| from middlewared.utils.privilege import credential_has_full_admin | ||
| from middlewared.utils.sid import sid_is_valid | ||
| from middlewared.utils.time_utils import utc_now | ||
| if TYPE_CHECKING: | ||
| from middlewared.main import Middleware |
There was a problem hiding this comment.
Middleware is unused, but this might be unavoidable. The flake8 error is F401.
Maybe add # noqa: F401
anodos325
force-pushed
the
user-api-keys
branch
2 times, most recently
from
f0744c4
to
cb5d4ac
Compare
anodos325
force-pushed
the
user-api-keys
branch
from
cb5d4ac
to
9df5d11
Compare
anodos325
force-pushed
the
user-api-keys
branch
from
5ed1ec4
to
344f44a
Compare
sonicaj
reviewed
Sep 28, 2024
| try: | ||
| if json.loads(row['allowlist']) != DEFAULT_ALLOW_LIST: | ||
| to_revoke.append(str(row['id'])) | ||
| except Exception: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The primary motivation for converting API keys so that they are explicitly linked to user accounts is to provide some method for TrueNAS Connect to use tie in to local or directory services accounts to a credential that is persistently stored in the TrueNAS Connect keychain.
The legacy API key mechanism was insufficient for this purpose because the mismatch between user accounts and API keys could lead to administrators retaining NAS access after account deletion, expiration, or locking. For more in-depth context and reasoning please refer to the internal design document NEP-053.
For this purpose, this commit makes the following changes:
revokedstate so that the system administrator has an opportunity to review and generate a new key and/or service account that provides the correct level of access.api_keyskey that contains a list of IDs for API keys that exist for the user.During development of this new feature, it was determined that the original API keys were written with insufficient hashing rounds leading to the following changes:
Since libpam is now used for all non-token authentication methods, a new auth login endpoint (auth.login_ex) was added to middleware to facilitate future enhancements for challenge-response authentication mechanisms. Authentication via username + password + OTP token has been converted to this new standard. This new endpoint is more closely aligned with standards and requirements in NIST SP 800-63B. In summary the following changes were made: