which checks that the user and token exist and are not expired, and then
generates the string to be matched with the pmxcfs-stored token shadow
config file.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
with the format:
<full token ID> <token value/UUID>
it is just used for token value generation/deletion via the User API,
token value verification will happen over pmxcfs/ipcc.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
the helper is modeled after the corresponding user method.
the 'tokenid' option goes into PVE::AccessControl, since we need it in
multiple API modules.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
token definitions/references in user.cfg always use the full form of the
token id, consisting of:
USER@REALM!TOKENID
token definitions are represented by their own lines prefixed with
'token', which need to come after the corresponding user definition, but
before any ACLs referencing them.
parsed representation in a user config hash is inside a new 'tokens'
element of the corresponding user object, using the unique-per-user
token id as key.
only token metadata is stored inside user.cfg / accessible via the
parsed user config hash. the actual token values will be stored
root-readable only in a separate (shadow) file.
'comment' and 'expire' have the same semantics as for users.
'privsep' determines whether an API token gets the full privileges of
the corresponding user, or just the intersection of privileges of the
corresponding user and those of the API token itself.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
it was useful for test-cases to verify the behaviour when pools where
introduced, but it is not used anywhere else in the code base and those
tests can also just check on permission-level.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
they have been handled by PVE::RPCEnvironment for quite some time
already, and the versions there are the complete ones that should be
actually used.
manager switched over their last use not long ago, in 6.0-9, so
record a Breaks to that version.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
we already have the API paths, and they make sense to get an overview
over user.cfg contents.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
since libpve-cluster-perl 6.0-8 this happens automatically when parsing
the datacenter.cfg, just like the other property strings stored there.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
since we read datacenter.cfg, and parse the u2f property string using a
format defined in PVE::DataCenterConfig.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
instead of parsing corosync.conf, and avoid coupling the access-control
API with PVE::Corosync. if corosync.conf and pmxcfs don't agree on how
the cluster is called, there is a bigger issue anyway..
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
it's not required for dependencies (since those are only ever between
sections, and not within), but makes for easier diffing.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
usernames are allowed to start with '@', so adding a user '@test@pve'
and adding it to an ACL should work, instead of ignoring that part of
the ACL entry.
So use verify_groupname to additionally enforce that the group name we
extracted does not include an additional @, as then it cannot be a
group.
note: there is no potential for user and group to be confused, since a
username must end with '@REALM', and a group reference in an ACL can
only contain one '@' (as first character).
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
we cannot fully close this window, and don't need to anyway since we
apply +-300s when calculating ticket age ranges, but documenting where
mtime is used and what we expect seems like a good idea for future
readers.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to shrink the window between the two file_set_contents calls. we don't
need the mtimes to line up exactly since we have 300s of uncertainty
anyway, but generating an RSA key could take a while ;)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to fix an issue where valid tickets could be rejected 5 minutes after a
key rotation, where the minimum age is exactly 0 seconds.
thanks Dominik for triaging!
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This activates the authkey rotation added in commits
1800a71a79c7cf49108e22781d2f34be87b1efd through
f7282aee6b
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This changed with the previous TFA changes.
In the long term, the plan is to let the user get into the
half-logged-in state and open the TFA configuration window
on the UI to allow them to finish their TFA setup, but for
now we restore the previous behavior.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
as it was binary data, which can contain everything, including '\0',
and this was cut off, making it impossible to login after
registration, as a borked publicKey got saved in tfa.cfg
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This allows for doing OTP TFA in two steps, first login with normal
credentials and get the half-logged-in ticket, then send the OTP
verification for full login, same as with u2f was already possible.
This allows for a nicer UI, as OTP fields can be shown on demand, and
do not need to be visible by default.
The old way of sending the OTP code immediately with the initial
credentials request still works for backward compatibility and as
some API user may prefer it.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Adds a priv/tfa.cfg file usable in place of user.cfg.
(Otherwise the user.cfg can potentially grow too big with
u2f keys.)
Also contains some preparation code for u2f and
user-opt-in totp.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
