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

[Jan Cholasta]

On 13.6.2014 21:59, Nathaniel McCallum wrote:

On Wed, 2014-06-11 at 12:43 -0400, Nathaniel McCallum wrote:

On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote:

On 05/13/2014 04:33 PM, Jan Cholasta wrote:

On 12.5.2014 21:02, Nathaniel McCallum wrote:

On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:

On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:

On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:

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 ?


These are the ACIs using the protected mechanism:

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor ||
ipatokenModel
|| ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
acl Users can read basic token info; allow (read, search, compare)
userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits ||
ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
allow (read, search, compare) userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl
Users can
see HOTP details; allow (read, search, compare) userattr =
ipatokenOwner#USERDN;)

aci: (targetfilter =
((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
description || ipatokenDisabled || ipatokenNotBefore ||
ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
ipatokenSerial)(version 3.0; acl Users can write basic token info;
allow (write) userattr = ipatokenOwner#USERDN;)

aci: (target =
ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
= ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version
3.0;
acl Users can create and delete tokens; allow (add, delete)
userattr =
ipatokenOwner#SELFDN;)

This is what they look like using managedBy (I have not tested this):

aci: 

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

[Martin Kosek]

On 06/16/2014 09:17 AM, Jan Cholasta wrote:
 On 13.6.2014 21:59, Nathaniel McCallum wrote:
 On Wed, 2014-06-11 at 12:43 -0400, Nathaniel McCallum wrote:
 On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote:
 On 05/13/2014 04:33 PM, Jan Cholasta wrote:
 On 12.5.2014 21:02, Nathaniel McCallum wrote:
 On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:
 On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
 On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
 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 ?

 These are the ACIs using the protected mechanism:

 aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
 objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
 ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor ||
 ipatokenModel
 || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
 acl Users can read basic token info; allow (read, search, compare)
 userattr = ipatokenOwner#USERDN;)

 aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
 ipatokenOTPalgorithm || ipatokenOTPdigits ||
 ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
 allow (read, search, compare) userattr = ipatokenOwner#USERDN;)

 aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
 ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl
 Users can
 see HOTP details; allow (read, search, compare) userattr =
 ipatokenOwner#USERDN;)

 aci: (targetfilter =
 ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
 description || ipatokenDisabled || ipatokenNotBefore ||
 ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
 ipatokenSerial)(version 3.0; acl Users can write basic token info;
 allow (write) userattr = ipatokenOwner#USERDN;)

 aci: (target =
 ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
 = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version
 3.0;
 acl Users can create and delete tokens; 

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

[Nathaniel McCallum]

On Wed, 2014-06-11 at 12:43 -0400, Nathaniel McCallum wrote:
 On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote:
  On 05/13/2014 04:33 PM, Jan Cholasta wrote:
   On 12.5.2014 21:02, Nathaniel McCallum wrote:
   On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:
   On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
   On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
   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 ?
  
   These are the ACIs using the protected mechanism:
  
   aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
   objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
   ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
   ipatokenModel
   || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
   acl Users can read basic token info; allow (read, search, compare)
   userattr = ipatokenOwner#USERDN;)
  
   aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
   ipatokenOTPalgorithm || ipatokenOTPdigits ||
   ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
   allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
  
   aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
   ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl 
   Users can
   see HOTP details; allow (read, search, compare) userattr =
   ipatokenOwner#USERDN;)
  
   aci: (targetfilter =
   ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
   description || ipatokenDisabled || ipatokenNotBefore ||
   ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
   ipatokenSerial)(version 3.0; acl Users can write basic token info;
   allow (write) userattr = ipatokenOwner#USERDN;)
  
   aci: (target 

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

[Nathaniel McCallum]

On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote:
 On 05/13/2014 04:33 PM, Jan Cholasta wrote:
  On 12.5.2014 21:02, Nathaniel McCallum wrote:
  On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:
  On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
  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 ?
 
  These are the ACIs using the protected mechanism:
 
  aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
  objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
  ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
  ipatokenModel
  || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
  acl Users can read basic token info; allow (read, search, compare)
  userattr = ipatokenOwner#USERDN;)
 
  aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits ||
  ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
  allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
 
  aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl 
  Users can
  see HOTP details; allow (read, search, compare) userattr =
  ipatokenOwner#USERDN;)
 
  aci: (targetfilter =
  ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
  description || ipatokenDisabled || ipatokenNotBefore ||
  ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
  ipatokenSerial)(version 3.0; acl Users can write basic token info;
  allow (write) userattr = ipatokenOwner#USERDN;)
 
  aci: (target = 
  ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
  = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 
  3.0;
  acl Users can create and delete tokens; allow 

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

[Nathaniel McCallum]

On Thu, 2014-06-05 at 08:45 +0200, Jan Cholasta wrote:
 On 28.5.2014 22:44, Nathaniel McCallum wrote:
  On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote:
  On 13.5.2014 19:12, Nathaniel McCallum wrote:
  On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote:
  On 12.5.2014 21:02, Nathaniel McCallum wrote:
  On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:
  On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
  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 ?
 
  These are the ACIs using the protected mechanism:
 
  aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
  objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
  ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
  ipatokenModel
  || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
  acl Users can read basic token info; allow (read, search, compare)
  userattr = ipatokenOwner#USERDN;)
 
  aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits ||
  ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
  allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
 
  aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users 
  can
  see HOTP details; allow (read, search, compare) userattr =
  ipatokenOwner#USERDN;)
 
  aci: (targetfilter =
  ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
  description || ipatokenDisabled || ipatokenNotBefore ||
  ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
  ipatokenSerial)(version 3.0; acl Users can write basic token info;
  allow (write) userattr = ipatokenOwner#USERDN;)
 
  aci: (target = 
  

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

[Jan Cholasta]

On 28.5.2014 22:44, Nathaniel McCallum wrote:

On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote:

On 13.5.2014 19:12, Nathaniel McCallum wrote:

On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote:

On 12.5.2014 21:02, Nathaniel McCallum wrote:

On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:

On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:

On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:

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 ?


These are the ACIs using the protected mechanism:

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
|| ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
acl Users can read basic token info; allow (read, search, compare)
userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits ||
ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
allow (read, search, compare) userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
see HOTP details; allow (read, search, compare) userattr =
ipatokenOwner#USERDN;)

aci: (targetfilter =
((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
description || ipatokenDisabled || ipatokenNotBefore ||
ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
ipatokenSerial)(version 3.0; acl Users can write basic token info;
allow (write) userattr = ipatokenOwner#USERDN;)

aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
= ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
acl Users can create and delete tokens; allow (add, delete) userattr =
ipatokenOwner#SELFDN;)

This is what they look like using managedBy (I have not tested this):

aci: 

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

[Martin Kosek]

On 06/05/2014 08:45 AM, Jan Cholasta wrote:
 On 28.5.2014 22:44, Nathaniel McCallum wrote:
 On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote:
 On 13.5.2014 19:12, Nathaniel McCallum wrote:
 On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote:
...
 Nathaniel can you send 2 lines showing the difference in ACIs between
 using managed-by vs a new attribute ?

 These are the ACIs using the protected mechanism:

 aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
 objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
 ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
 ipatokenModel
 || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
 acl Users can read basic token info; allow (read, search, compare)
 userattr = ipatokenOwner#USERDN;)

 aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
 ipatokenOTPalgorithm || ipatokenOTPdigits ||
 ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
 allow (read, search, compare) userattr = ipatokenOwner#USERDN;)

 aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
 ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users 
 can
 see HOTP details; allow (read, search, compare) userattr =
 ipatokenOwner#USERDN;)

 aci: (targetfilter =
 ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
 description || ipatokenDisabled || ipatokenNotBefore ||
 ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
 ipatokenSerial)(version 3.0; acl Users can write basic token info;
 allow (write) userattr = ipatokenOwner#USERDN;)

 aci: (target = 
 ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
 = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
 acl Users can create and delete tokens; allow (add, delete) userattr 
 =
 ipatokenOwner#SELFDN;)

 This is what they look like using managedBy (I have not tested this):

 aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
 objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
 ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
 ipatokenModel
 || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
 acl Users can read basic token info; allow (read, search, compare)
 userattr = ipatokenOwner#USERDN; allow (read, search, compare)
 userattr = managedBy#USERDN;)

 aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
 ipatokenOTPalgorithm || ipatokenOTPdigits ||
 ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
 allow (read, search, compare) userattr = ipatokenOwner#USERDN; allow
 (read, search, compare) userattr = managedBy#USERDN;)

 aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
 ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users 
 can
 see HOTP details; allow (read, search, compare) userattr =
 ipatokenOwner#USERDN; allow (read, search, compare) userattr =
 managedBy#USERDN;)

 aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
 description || ipatokenDisabled || ipatokenNotBefore ||
 ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
 ipatokenSerial)(version 3.0; acl Managers can write basic token 
 info;
 allow (write) userattr = managedBy#USERDN;)

 aci: (targetfilter = (objectClass=ipaToken))(version 3.0; acl
 Managers can delete tokens; allow (delete) userattr =
 managedBy#USERDN;)

 aci: (target = 
 ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
 = (objectClass=ipaToken))(version 3.0; acl Users can create
 self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and
 userattr = managedBy#SELFDN;)

 In short:
 1. Owner and manager get read, search and compare.
 2. Manager gets write (to select attributes) and delete.
 3. Users can create self-managed tokens for themselves only.

 The otptoken-add command should gain the following defaults:
 1. The owner defaults to the user adding the token.
 2. If owner == user adding token, managedBy defaults to owner.
 3. Otherwise, managedBy defaults to None.

 This means that if neither owner nor managedBy are specified, the
 default is a self-owned, self-managed token. Likewise, if a different
 owner is specified, no manager is assumed.

 rcrit expresses worry that ipalib's ACI parser may not handle the above
 syntax. This will become clear during testing if we want this approach.

 Does this look sane?

 I am not entirely sure your ACI syntax is always right for the second
 set. and perhaps we want to duplicate ACIs in some cases (once for owner
 once for manager).

 I think the read ACIs do not need to list managedby ? Do we plan to have
 a manager that is another regular user but not the owner nor an admin ?

 In any case I prefer the sytnax that uses managedby, as it has more
 potential.

 Attached is a new version of the patch which implements the feature
 using managedBy instead of ipatokenProtected. One important thing needs
 to be said about this patch. I am not exposing managedBy in either the
 UI, the CLI or LDAP (ACI). 

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

[Jan Cholasta]

On 13.5.2014 19:12, Nathaniel McCallum wrote:

On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote:

On 12.5.2014 21:02, Nathaniel McCallum wrote:

On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:

On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:

On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:

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 ?


These are the ACIs using the protected mechanism:

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
|| ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
acl Users can read basic token info; allow (read, search, compare)
userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits ||
ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
allow (read, search, compare) userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
see HOTP details; allow (read, search, compare) userattr =
ipatokenOwner#USERDN;)

aci: (targetfilter =
((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
description || ipatokenDisabled || ipatokenNotBefore ||
ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
ipatokenSerial)(version 3.0; acl Users can write basic token info;
allow (write) userattr = ipatokenOwner#USERDN;)

aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
= ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
acl Users can create and delete tokens; allow (add, delete) userattr =
ipatokenOwner#SELFDN;)

This is what they look like using managedBy (I have not tested this):

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || 

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

[Jan Cholasta]

On 12.5.2014 21:02, Nathaniel McCallum wrote:

On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:

On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:

On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:

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 ?


These are the ACIs using the protected mechanism:

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
|| ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
acl Users can read basic token info; allow (read, search, compare)
userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits ||
ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
allow (read, search, compare) userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
see HOTP details; allow (read, search, compare) userattr =
ipatokenOwner#USERDN;)

aci: (targetfilter =
((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
description || ipatokenDisabled || ipatokenNotBefore ||
ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
ipatokenSerial)(version 3.0; acl Users can write basic token info;
allow (write) userattr = ipatokenOwner#USERDN;)

aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
= ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
acl Users can create and delete tokens; allow (add, delete) userattr =
ipatokenOwner#SELFDN;)

This is what they look like using managedBy (I have not tested this):

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
|| ipatokenSerial 

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

[Nathaniel McCallum]

On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote:
 On 12.5.2014 21:02, Nathaniel McCallum wrote:
  On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:
  On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
  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 ?
 
  These are the ACIs using the protected mechanism:
 
  aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
  objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
  ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
  || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
  acl Users can read basic token info; allow (read, search, compare)
  userattr = ipatokenOwner#USERDN;)
 
  aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits ||
  ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
  allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
 
  aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
  see HOTP details; allow (read, search, compare) userattr =
  ipatokenOwner#USERDN;)
 
  aci: (targetfilter =
  ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
  description || ipatokenDisabled || ipatokenNotBefore ||
  ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
  ipatokenSerial)(version 3.0; acl Users can write basic token info;
  allow (write) userattr = ipatokenOwner#USERDN;)
 
  aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
  = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
  acl Users can create and delete tokens; allow (add, delete) userattr =
  ipatokenOwner#SELFDN;)
 
  This is what they look like 

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

[Nathaniel McCallum]

On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:
 On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
   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 ?
  
  These are the ACIs using the protected mechanism:
  
  aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
  objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
  ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
  || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
  acl Users can read basic token info; allow (read, search, compare)
  userattr = ipatokenOwner#USERDN;)
  
  aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits ||
  ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
  allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
  
  aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
  see HOTP details; allow (read, search, compare) userattr =
  ipatokenOwner#USERDN;)
  
  aci: (targetfilter =
  ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
  description || ipatokenDisabled || ipatokenNotBefore ||
  ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
  ipatokenSerial)(version 3.0; acl Users can write basic token info;
  allow (write) userattr = ipatokenOwner#USERDN;)
  
  aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
  = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
  acl 

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

[Nathaniel McCallum]

On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
 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 ?

These are the ACIs using the protected mechanism:

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
|| ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
acl Users can read basic token info; allow (read, search, compare)
userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits ||
ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
allow (read, search, compare) userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
see HOTP details; allow (read, search, compare) userattr =
ipatokenOwner#USERDN;)

aci: (targetfilter =
((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
description || ipatokenDisabled || ipatokenNotBefore ||
ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
ipatokenSerial)(version 3.0; acl Users can write basic token info;
allow (write) userattr = ipatokenOwner#USERDN;)

aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
= ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
acl Users can create and delete tokens; allow (add, delete) userattr =
ipatokenOwner#SELFDN;)

This is what they look like using managedBy (I have not tested this):

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
|| 

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

[Simo Sorce]

On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
 On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
  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 ?
 
 These are the ACIs using the protected mechanism:
 
 aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
 objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
 ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
 || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
 acl Users can read basic token info; allow (read, search, compare)
 userattr = ipatokenOwner#USERDN;)
 
 aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
 ipatokenOTPalgorithm || ipatokenOTPdigits ||
 ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
 allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
 
 aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
 ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
 see HOTP details; allow (read, search, compare) userattr =
 ipatokenOwner#USERDN;)
 
 aci: (targetfilter =
 ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
 description || ipatokenDisabled || ipatokenNotBefore ||
 ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
 ipatokenSerial)(version 3.0; acl Users can write basic token info;
 allow (write) userattr = ipatokenOwner#USERDN;)
 
 aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
 = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
 acl Users can create and delete tokens; allow (add, delete) userattr =
 ipatokenOwner#SELFDN;)
 
 This is what they look like using managedBy (I have not tested this):
 
 aci: (targetfilter = 

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

[Nathaniel McCallum]

On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:
 On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:
  On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:
   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 ?
  
  These are the ACIs using the protected mechanism:
  
  aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
  objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
  ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
  || ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
  acl Users can read basic token info; allow (read, search, compare)
  userattr = ipatokenOwner#USERDN;)
  
  aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits ||
  ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
  allow (read, search, compare) userattr = ipatokenOwner#USERDN;)
  
  aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
  ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
  see HOTP details; allow (read, search, compare) userattr =
  ipatokenOwner#USERDN;)
  
  aci: (targetfilter =
  ((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
  description || ipatokenDisabled || ipatokenNotBefore ||
  ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
  ipatokenSerial)(version 3.0; acl Users can write basic token info;
  allow (write) userattr = ipatokenOwner#USERDN;)
  
  aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
  = ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
  acl 

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

[Rob Crittenden]

Nathaniel McCallum wrote:

On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote:

On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote:

On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote:

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 ?


These are the ACIs using the protected mechanism:

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
|| ipatokenSerial || ipatokenOwner || ipatokenProtected)(version 3.0;
acl Users can read basic token info; allow (read, search, compare)
userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenTOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits ||
ipatokenTOTPtimeStep)(version 3.0; acl Users can see TOTP details;
allow (read, search, compare) userattr = ipatokenOwner#USERDN;)

aci: (targetfilter = (objectClass=ipatokenHOTP))(targetattrs =
ipatokenOTPalgorithm || ipatokenOTPdigits)(version 3.0; acl Users can
see HOTP details; allow (read, search, compare) userattr =
ipatokenOwner#USERDN;)

aci: (targetfilter =
((objectClass=ipaToken)(!(ipatokenProtected=TRUE(targetattrs =
description || ipatokenDisabled || ipatokenNotBefore ||
ipatokenNotAfter || ipatokenVendor || ipatokenModel ||
ipatokenSerial)(version 3.0; acl Users can write basic token info;
allow (write) userattr = ipatokenOwner#USERDN;)

aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
= ((objectClass=ipaToken)(!(ipatokenProtected=TRUE)(version 3.0;
acl Users can create and delete tokens; allow (add, delete) userattr =
ipatokenOwner#SELFDN;)

This is what they look like using managedBy (I have not tested this):

aci: (targetfilter = (objectClass=ipaToken))(targetattrs =
objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
|| ipatokenSerial || ipatokenOwner || 

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

[Jan Cholasta]

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?

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.


Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

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

[Nathaniel McCallum]

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.

Nathaniel


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

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

[Dmitri Pal]

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.


Nathaniel


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [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

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

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

[Nathaniel McCallum]

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

Nathaniel
From 4340378d134e294d8c9e74673f9302d59f76a779 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Fri, 2 May 2014 16:44:30 -0400
Subject: [PATCH] Add support for protected tokens

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
https://fedorahosted.org/freeipa/ticket/4259
---
 install/share/70ipaotp.ldif|  3 ++-
 install/share/default-aci.ldif | 10 +-
 install/updates/40-otp.update  | 16 +++-
 ipalib/plugins/otptoken.py |  9 +
 ipalib/plugins/user.py |  9 -
 5 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/install/share/70ipaotp.ldif b/install/share/70ipaotp.ldif
index a40ad9ee0cfcf72ed6b79306396a29683f9e1a9d..08f639b6cd14b6dd1270a604fdd061cecb4a6482 100644
--- a/install/share/70ipaotp.ldif
+++ b/install/share/70ipaotp.ldif
@@ -23,7 +23,8 @@ attributeTypes: (2.16.840.1.113730.3.8.16.1.18 NAME 'ipatokenRadiusTimeout' DESC
 attributeTypes: (2.16.840.1.113730.3.8.16.1.19 NAME 'ipatokenRadiusRetries' DESC 'Number of allowed Retries' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA OTP')
 attributeTypes: (2.16.840.1.113730.3.8.16.1.20 NAME 'ipatokenUserMapAttribute' DESC 'Attribute to map from the user entry for RADIUS server authentication' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA OTP')
 attributeTypes: (2.16.840.1.113730.3.8.16.1.21 NAME 'ipatokenHOTPcounter' DESC 'HOTP counter' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA OTP')
-objectClasses:  (2.16.840.1.113730.3.8.16.2.1  NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial) X-ORIGIN 'IPA OTP')
+attributeTypes: (2.16.840.1.113730.3.8.16.1.22 NAME 'ipatokenProtected' DESC 'Optionally marks token as Protected' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA OTP')
+objectClasses:  (2.16.840.1.113730.3.8.16.2.1  NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial $ ipatokenProtected) X-ORIGIN 'IPA OTP')
 objectClasses:  (2.16.840.1.113730.3.8.16.2.2  NAME 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) X-ORIGIN 'IPA OTP')
 objectClasses:  

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

[Nathaniel McCallum]

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
From fea0835c9b55223944a8455451b14ab3bc13eace Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Fri, 2 May 2014 16:44:30 -0400
Subject: [PATCH] Add support for protected tokens

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
https://fedorahosted.org/freeipa/ticket/4259
---
 install/share/70ipaotp.ldif|  3 ++-
 install/share/default-aci.ldif | 10 +-
 install/updates/40-otp.update  | 16 +++-
 ipalib/plugins/otptoken.py | 11 +--
 ipalib/plugins/user.py |  9 -
 5 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/install/share/70ipaotp.ldif b/install/share/70ipaotp.ldif
index a40ad9ee0cfcf72ed6b79306396a29683f9e1a9d..08f639b6cd14b6dd1270a604fdd061cecb4a6482 100644
--- a/install/share/70ipaotp.ldif
+++ b/install/share/70ipaotp.ldif
@@ -23,7 +23,8 @@ attributeTypes: (2.16.840.1.113730.3.8.16.1.18 NAME 'ipatokenRadiusTimeout' DESC
 attributeTypes: (2.16.840.1.113730.3.8.16.1.19 NAME 'ipatokenRadiusRetries' DESC 'Number of allowed Retries' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA OTP')
 attributeTypes: (2.16.840.1.113730.3.8.16.1.20 NAME 'ipatokenUserMapAttribute' DESC 'Attribute to map from the user entry for RADIUS server authentication' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA OTP')
 attributeTypes: (2.16.840.1.113730.3.8.16.1.21 NAME 'ipatokenHOTPcounter' DESC 'HOTP counter' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA OTP')
-objectClasses:  (2.16.840.1.113730.3.8.16.2.1  NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial) X-ORIGIN 'IPA OTP')
+attributeTypes: (2.16.840.1.113730.3.8.16.1.22 NAME 'ipatokenProtected' DESC 'Optionally marks token as Protected' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA OTP')
+objectClasses:  (2.16.840.1.113730.3.8.16.2.1  NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial $ ipatokenProtected) X-ORIGIN 'IPA OTP')
 objectClasses:  (2.16.840.1.113730.3.8.16.2.2  NAME 

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

[Dmitri Pal]

On 05/06/2014 11:08 AM, 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


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Have we recorded any new OIDs added as a part of this OTP cleanup in our 
OID registry?
If not we should collect all added attributes and make sure they are 
recorded.


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

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

[Nathaniel McCallum]

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.
From a95e3cee5fdd7b98635d984977cbb71ad5c7aa02 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Fri, 2 May 2014 16:44:30 -0400
Subject: [PATCH] Add support for protected tokens

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
---
 install/share/70ipaotp.ldif|  3 ++-
 install/share/default-aci.ldif | 10 +-
 install/updates/40-otp.update  | 16 +++-
 ipalib/plugins/otptoken.py |  9 +
 ipalib/plugins/user.py |  9 -
 5 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/install/share/70ipaotp.ldif b/install/share/70ipaotp.ldif
index a40ad9ee0cfcf72ed6b79306396a29683f9e1a9d..08f639b6cd14b6dd1270a604fdd061cecb4a6482 100644
--- a/install/share/70ipaotp.ldif
+++ b/install/share/70ipaotp.ldif
@@ -23,7 +23,8 @@ attributeTypes: (2.16.840.1.113730.3.8.16.1.18 NAME 'ipatokenRadiusTimeout' DESC
 attributeTypes: (2.16.840.1.113730.3.8.16.1.19 NAME 'ipatokenRadiusRetries' DESC 'Number of allowed Retries' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA OTP')
 attributeTypes: (2.16.840.1.113730.3.8.16.1.20 NAME 'ipatokenUserMapAttribute' DESC 'Attribute to map from the user entry for RADIUS server authentication' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA OTP')
 attributeTypes: (2.16.840.1.113730.3.8.16.1.21 NAME 'ipatokenHOTPcounter' DESC 'HOTP counter' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA OTP')
-objectClasses:  (2.16.840.1.113730.3.8.16.2.1  NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial) X-ORIGIN 'IPA OTP')
+attributeTypes: (2.16.840.1.113730.3.8.16.1.22 NAME 'ipatokenProtected' DESC 'Optionally marks token as Protected' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA OTP')
+objectClasses:  (2.16.840.1.113730.3.8.16.2.1  NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial $ ipatokenProtected) X-ORIGIN 'IPA OTP')
 objectClasses:  (2.16.840.1.113730.3.8.16.2.2  NAME 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) X-ORIGIN 'IPA OTP')
 objectClasses:  (2.16.840.1.113730.3.8.16.2.3  NAME 'ipatokenRadiusProxyUser' SUP top AUXILIARY DESC 'Radius Proxy User' MAY (ipatokenRadiusConfigLink $ ipatokenRadiusUserName) X-ORIGIN 'IPA OTP')
 objectClasses:  (2.16.840.1.113730.3.8.16.2.4  NAME 'ipatokenRadiusConfiguration' SUP top STRUCTURAL DESC 'Proxy Radius Configuration' MUST (cn $ ipatokenRadiusServer $