This also constitutes a rethinking of the token ACIs after the introduction
of SELFDN support.
Admins, as before, have full access to all token permissions.
Normal users have read/search/compare access to all of the non-secret data
for tokens assigned to them, whether managed by them or not. Users can add
tokens if, and only if, they will also manage this token.
Managers can also read/search/compare tokens they manage. Additionally,
they can write non-secret data to their managed tokens and delete them.
When a normal user self-creates a token (the default behavior), then
managedBy is automatically set. When an admin creates a token for another
user (or no owner is assigned at all), then managed by is not set. In this
second case, the token is effectively read-only for the assigned owner.
This behavior enables two important other behaviors. First, an admin can
create a hardware token and assign it to the user as a read-only token.
Second, when the user is deleted, only his self-managed tokens are deleted.
All other (read-only) tokens are instead orphaned. This permits the same
token object to be reasigned to another user without loss of any counter
data.
https://fedorahosted.org/freeipa/ticket/4228https://fedorahosted.org/freeipa/ticket/4259
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Creating tokens for yourself is the most common operation. Making this the
default optimizes for the common case.
Reviewed-By: Simo Sorce <simo@redhat.com>
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Specifying the default in the LDAP Object causes the parameter to be specified
for non-add operations. This is especially problematic when performing the
modify operation as it causes the primary key to change for every
modification.
https://fedorahosted.org/freeipa/ticket/4227
Reviewed-By: Petr Viktorin <pviktori@redhat.com>
RFC 4226 states the following in section 4:
R6 - The algorithm MUST use a strong shared secret. The length of
the shared secret MUST be at least 128 bits. This document
RECOMMENDs a shared secret length of 160 bits.
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
We had originally decided to provide defaults on the server side so that they
could be part of a global config for the admin. However, on further reflection,
only certain defaults really make sense given the limitations of Google
Authenticator. Similarly, other defaults may be token specific.
Attempting to handle defaults on the server side also makes both the UI and
the generated documentation unclear.
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Nathaniel McCallum
Petr Viktorin