[Freeipa-devel] [PATCH 0049] Add support for protected tokens

[Simo Sorce]

On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote:
> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote:
> > On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote:
> >> Hi,
> >>
> >> 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.
> >>>>>
> >>>>> https://fedorahosted.org/freeipa/ticket/4228
> >>>>>
> >>>>> 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:
> >>>>
> >>>> https://fedorahosted.org/freeipa/ticket/4259
> >>> 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.
> >>>
> >>> Nathaniel
> >> Is using the ipatokenprotected attribute the final design?
> > No. Alternate designs are welcome. The code is easy enough to modify.
> >
> >> 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.
> > It seems to me that the mechanics of this are roughly the same as
> > protected, just with a different syntax. The cost of this is more
> > complex ACIs. In particular, we'd have to use two userdn clauses (is
> > this possible?) instead of a simple filter. If there is a clear benefit,
> > we can justify the more obtuse syntax.
> 
> We usually try not to create new attributes until it is fully justified.
> I would like Simo to chime in on this.

I would also prefer to reuse existing attributes and mechanism if
possible and if it will not preclude future work.

In this case, it "sounds" like managed-by has the appropriate meaning:
"who manages the token ?" -> myself, admin, other, none ?

Nathaniel can you send 2 lines showing the difference in ACIs between
using managed-by vs a new attribute ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York