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

Martin Kosek mkosek at redhat.com
Thu Jun 5 08:00:32 UTC 2014


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). Do we care about this? If yes, should I
>>>>>> expose this similar to owner or as a relationship?
>>>>>
>>>>> I would expose it, as a relationship. (Note that ipatokenowner should
>>>>> ideally be represented as a relationship too, but the framework does not
>>>>> support 1-to-many relationships ATM.)
>>>>
>>>> So since this is a 1-to-many relationship we shouldn't expose it?
>>>>
>>>> Or should I do it like owner is currently done?
>>>
>>> Do it like managedby is done in the host plugin (see
>>> "attribute_members", "relationships", etc.)
>>>
>>>>
>>>>>
>>>>> Just curious, why are the ACIs divided like this:
>>>>>
>>>>>        aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs =
>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
>>>>> || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers
>>>>> can read basic token info"; allow (read, search, compare) userattr =
>>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)
>>>>>        aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs =
>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits ||
>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP
>>>>> details"; allow (read, search, compare) userattr =
>>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)
>>>>>        aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs =
>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl
>>>>> "Users/managers can see HOTP details"; allow (read, search, compare)
>>>>> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)
>>>>>
>>>>> IMHO you could make them less complex by dividing them like this:
>>>>>
>>>>>        aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs =
>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
>>>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm ||
>>>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can
>>>>> read token details"; allow (read, search, compare) userattr =
>>>>> "ipatokenOwner#USERDN";)
>>>>>        aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs =
>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled ||
>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel
>>>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm ||
>>>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers
>>>>> can read token details"; allow (read, search, compare) userattr =
>>>>> "managedBy#USERDN";)
>>>>
>>>> The first set is organized by objectClass. The second by userattr. I
>>>> have no strong opinion on this matter, though performance is probably a
>>>> consideration. Do any DS guys want to chime in?
...
>> 2. I can't figure out how to get the framework to actually show
>> managedBy in command output (like otptoken-show). This means you can
>> add/remove relationships using otptoken-add-managedby and
>> otptoken-remove-managedby, but you can't actually see the list of
>> managers. What am I missing?
> 
> In the hbacrule or selinuxusermap plugins it is done by adding an "invisible"
> param to the object plugin, like this:
> 
>     Str('managedby_user?',
>         label=_('Manager'),
>         flags=['no_create', 'no_update', 'no_search'],
>     ),
> 
>>
>> Also, it would be helpful if someone with DS expertise could answer the
>> question about the performance of the ACI structure options as listed
>> above.
> 
> +1

CCing Ludwig to advise on the ACIs.

Martin




More information about the Freeipa-devel mailing list