On 6.5.2014 17:08, Nathaniel McCallum wrote:
On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote:
On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote:
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 protected or non-protected.
Users can add or delete non-protected tokens and modify most of their
metadata. However they cannot create, delete or modify protected tokens.
Regardless of whether the token is protected or not, users cannot change
a token's ownership or unique identity.

In contrast, admins can create protected tokens. This protects the token
from deletion or modification when assigned to users. Additionally, when
a user account is deleted, the assigned non-protected tokens are deleted
but the protected tokens are merely orphaned. This permits the token to
be reassigned without having to recreate it. This last point is
particularly useful in the case of hardware tokens.


NOTE: This patch depends on my patch 0048.

This new version makes ipatokenDisabled visible for token owners. It is
also writable if the token is non-protected. This additionally fixes:


This new version changes the way the default value of protected is setup
in accordance with the changes made for the review of my patch 0048.2.


Is using the ipatokenprotected attribute the final design?

I did not dig too deep into this, but I think it might be better to instead use the managedby attribute on a token to limit who can delete (or administer in other way) the token. On otptoken-add, managedby would be set to the "whoami" user DN, unless run with --protected, in which case managedby would be left empty. Then, when deleting a user, the token would be deleted only if the user manages the token.


Jan Cholasta

Freeipa-devel mailing list

Reply via email to