On 09/22/2014 05:37 PM, Martin Kosek wrote:
On 09/20/2014 10:22 PM, Nathaniel McCallum wrote:
On Wed, 2014-09-17 at 12:31 +0200, Martin Kosek wrote:
On 09/17/2014 08:51 AM, Jan Cholasta wrote:
Hi,
Dne 16.9.2014 v 19:32 Nathaniel McCallum napsal(a):
We perform this enforcement at the API level since:
* DS level enforcement would be difficult
* ipatokenUniqueID generation already happens at the API level
It may be nice in the future to perform enforcement in the DS itself.
However, the question of the location of enforcement is largely an
aesthetic issue.
https://fedorahosted.org/freeipa/ticket/4456
That's a rather beefy check. I would prefer something like this (untested):
group_dn = self.api.Object.group.get_dn(u'admins')
filter = ldap.make_filter(
{'krbprincipalname': context.principal, 'memberof': group_dn},
ldap.MATCH_ALL)
try:
ldap.find_entries(
base_dn=self.api.env.basedn, filter=filter, attrs_list=[''])
except errors.NotFound:
raise ValidationError(name='ipatokenuniqueid',
error='can only be specified by admins')
Honza
Also, do we want to hard code it to admins group only?
Preferably, no. But I don't have another workable solution.
Wouldn't it be more
flexible to create a new Virtual Operation and let realm admin configure who
can change the UID. See Jan's patch d6fb110b77e2c585f0bfc5eb11b0187a43263fa1
for an example how that's done.
Modifications are already not permitted. The problem is that we need to
restrict the format of an attribute for only some users on add only.
Nathaniel
Ah, that's a valid point. We need some way to get the modified DN after UUID
generation.
I discussed this issue briefly with Nathaniel and I had an idea. Doesn't DS
have a control for modification to return an updated object after ldapmodify?
Do you mean RFC 4527 (read entry control). Ability to read our writes.
thierry
Then we could trigger it, get the DN and work with that DN in the token plugin.
We do not need to make it super general in the framework right now, but we
could do at least some minimal version for the token use case.
Martin
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
