[389-devel] Re: [discuss] composable object types in lib389
> On 17 Jan 2019, at 19:40, Ludwig Krispenz wrote: > > > Maybe I do not understand how it works because of some lib389 magic, but I > think this is not how roles work. > > You are creating cn=tuser1 and cn=Anju and they will have the role > objectclasses, but the benefit of roles is that you do NOT have to touch the > useres to assign roles to them. There is a class of users and a class of role > definitions and ONLY the change in the role definition will determine if a > user has a role or not. I think lib389 probably isn’t helping, but Ludwig’s description here is correct. Maybe a good approach is to “setup” roles by hand, then once you have a process in mind, then you can make the lib389 parts? I generally approach things this way to understand them well. Would that help? — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Re: [discuss] composable object types in lib389
On 01/17/2019 09:57 AM, Anuj Borah wrote:
Hay William.
Here i am not using nsUserAccount in nsUserAccountRole as it
requires 'uid' which is not allowed in nsFilteredRoleDefinition and
nsRoleDefinition . Below are usages:
user=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
user.create(properties=user_props, basedn=SUFFIX)
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[0].dn
>> 'cn=tuser1,ou=People,dc=example,dc=com'
nsUserAccountRoles(topo.standalone,
DEFAULT_SUFFIX).create(properties=user_props)
>>>
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[1].dn
>>> 'cn=Anuj,ou=People,dc=example,dc=com'
Let me know , what you think .
Maybe I do not understand how it works because of some lib389 magic, but
I think this is not how roles work.
You are creating cn=tuser1 and cn=Anju and they will have the role
objectclasses, but the benefit of roles is that you do NOT have to touch
the useres to assign roles to them. There is a class of users and a
class of role definitions and ONLY the change in the role definition
will determine if a user has a role or not.
Regards
Anuj Borah
On Tue, Jan 15, 2019 at 6:30 AM William Brown > wrote:
> On 14 Jan 2019, at 19:28, Anuj Borah mailto:abo...@redhat.com>> wrote:
>
> Hi William ,
>
> Just find out a way to do it .
This isn’t quite what I had in mind.
Remember, we should be able to compose nsRole types to various
other objects if required (despite my dislike of nsRoles …).
We have "nsUserAccount(Account)”, and we need to be able to extend
it with nsRole types.
One way to achieve this is:
class nsRoleDefinition(object):
def __init__(self, instance, dn=None):
if ‘_create_objectclasses’ not in self:
raise Exception ….
# So we must have been combined with a type to add roles
self._create_objectclasses.append(’nsFilteredRoleDefinition’)
class nsUserAccountRole(nsUserAccount, nsRoleDefinition):
def __init__(self, instance, dn=None):
super(nsUserAccount, self).__init__(instance, dn)
super(nsRoleDefinition, self).__init__(instance, dn)
Then you would use the nsUserAccountRole like normal. (I think we
may need a similar “nsUserAccountRoles" for the muliple search parts)
A benefit to this, is you could have role-specific functions like
setting/changing the filter, but you never loose the “account”
features like bind. Provided a method is uniquely sourced, I think
python takes the implementation that is unique, or it takes the
“first”. So this should all just work.
The main benefit here is it’s really clean, we can compose this to
other types. It also avoids any duplication of class definitions
and logic etc.
I think this is how I would like to see it created. It may be
worth making a “ticket” just for the nsRole parts and splitting
your test for nsRoles out of the mega-patch you have.
>
> class UserAccountnsRole(Account):
>
> def __init__(self, instance, dn=None):
> super(UserAccountnsRole, self).__init__(instance, dn)
> self._rdn_attribute = RDN
> self._create_objectclasses = [
> 'top',
> 'LDAPsubentry',
> 'nsRoleDefinition',
> 'nsComplexRoleDefinition',
> 'nsFilteredRoleDefinition'
> ]
> user_compare_exclude = [
> 'nsUniqueId',
> 'modifyTimestamp',
> 'createTimestamp',
> 'entrydn'
> ]
> self._compare_exclude = self._compare_exclude +
user_compare_exclude
> self._protected = False
>
> def _validate(self, rdn, properties, basedn):
> if 'ntUserDomainId' in properties and 'ntUser' not in
self._create_objectclasses:
> self._create_objectclasses.append('ntUser')
>
> return super(UserAccountnsRole, self)._validate(rdn,
properties, basedn)
>
>
> def create_test_user_nsrole(instance, cn, nsRoleFilter,
description, suffix=None):
> global test_user_id
> if cn is None:
> cn = "testuser_" + str(test_user_id)
> test_user_id += 1
> if suffix is None:
> suffix = DEFAULT_SUFFIX
> dn = "cn=" + cn + "," + suffix
> properties = {
> 'cn': cn,
> "nsRoleFilter": nsRoleFilter,
> "description": description,
> }
> user = UserAccountnsRole(instance, dn)
> user.create(properties=properties)
> return user
> Now just using create_test_user_nsrole we will be able to create
entries with nsRoles.
>
>
> Regards
> Anuj Borah
>
>
>
>
>
>
> On Mon, Jan 7, 2019 at 2:30 PM
[389-devel] Re: [discuss] composable object types in lib389
Hay William.
RDN = 'cn'
class nsUserAccountRole(Account):
def __init__(self, instance, dn=None):
super(nsUserAccountRole, self).__init__(instance, dn)
self._rdn_attribute = RDN
self._create_objectclasses = [
'top',
'LDAPsubentry',
'nsRoleDefinition',
'nsComplexRoleDefinition',
'nsFilteredRoleDefinition'
]
self._childobject = Account
user_compare_exclude = [
'nsUniqueId',
'modifyTimestamp',
'createTimestamp',
'entrydn'
]
self._compare_exclude = self._compare_exclude + user_compare_exclude
self._protected = False
class nsUserAccountRoles(DSLdapObjects):
def __init__(self, instance, basedn, rdn='ou=People'):
super(nsUserAccountRoles, self).__init__(instance)
self._objectclasses = [
'top',
'LDAPsubentry',
'nsRoleDefinition',
'nsComplexRoleDefinition',
'nsFilteredRoleDefinition'
]
self._filterattrs = [RDN, 'cn']
self._childobject = nsUserAccountRole
if rdn is None:
self._basedn = basedn
else:
self._basedn = '{},{}'.format(rdn, basedn)
Here i am not using nsUserAccount in nsUserAccountRole as it requires
'uid' which is not allowed in nsFilteredRoleDefinition and
nsRoleDefinition . Below are usages:
user=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
user.create(properties=user_props, basedn=SUFFIX)
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[0].dn
>> 'cn=tuser1,ou=People,dc=example,dc=com'
nsUserAccountRoles(topo.standalone,
DEFAULT_SUFFIX).create(properties=user_props)
>>>
nsUserAccountRoles(topo.standalone, DEFAULT_SUFFIX).list()[1].dn
>>> 'cn=Anuj,ou=People,dc=example,dc=com'
Let me know , what you think .
Regards
Anuj Borah
On Tue, Jan 15, 2019 at 6:30 AM William Brown wrote:
>
> > On 14 Jan 2019, at 19:28, Anuj Borah wrote:
> >
> > Hi William ,
> >
> > Just find out a way to do it .
>
>
> This isn’t quite what I had in mind.
>
> Remember, we should be able to compose nsRole types to various other
> objects if required (despite my dislike of nsRoles …).
>
> We have "nsUserAccount(Account)”, and we need to be able to extend it with
> nsRole types.
>
> One way to achieve this is:
>
> class nsRoleDefinition(object):
> def __init__(self, instance, dn=None):
> if ‘_create_objectclasses’ not in self:
> raise Exception ….
> # So we must have been combined with a type to add roles
> self._create_objectclasses.append(’nsFilteredRoleDefinition’)
>
>
> class nsUserAccountRole(nsUserAccount, nsRoleDefinition):
> def __init__(self, instance, dn=None):
> super(nsUserAccount, self).__init__(instance, dn)
> super(nsRoleDefinition, self).__init__(instance, dn)
>
>
>
> Then you would use the nsUserAccountRole like normal. (I think we may need
> a similar “nsUserAccountRoles" for the muliple search parts)
>
> A benefit to this, is you could have role-specific functions like
> setting/changing the filter, but you never loose the “account” features
> like bind. Provided a method is uniquely sourced, I think python takes the
> implementation that is unique, or it takes the “first”. So this should all
> just work.
>
> The main benefit here is it’s really clean, we can compose this to other
> types. It also avoids any duplication of class definitions and logic etc.
>
> I think this is how I would like to see it created. It may be worth making
> a “ticket” just for the nsRole parts and splitting your test for nsRoles
> out of the mega-patch you have.
>
> >
> > class UserAccountnsRole(Account):
> >
> > def __init__(self, instance, dn=None):
> > super(UserAccountnsRole, self).__init__(instance, dn)
> > self._rdn_attribute = RDN
> > self._create_objectclasses = [
> > 'top',
> > 'LDAPsubentry',
> > 'nsRoleDefinition',
> > 'nsComplexRoleDefinition',
> > 'nsFilteredRoleDefinition'
> > ]
> > user_compare_exclude = [
> > 'nsUniqueId',
> > 'modifyTimestamp',
> > 'createTimestamp',
> > 'entrydn'
> > ]
> > self._compare_exclude = self._compare_exclude +
> user_compare_exclude
> > self._protected = False
> >
> > def _validate(self, rdn, properties, basedn):
> > if 'ntUserDomainId' in properties and 'ntUser' not in
> self._create_objectclasses:
> > self._create_objectclasses.append('ntUser')
> >
> > return super(UserAccountnsRole, self)._validate(rdn, properties,
> basedn)
> >
> >
> > def create_test_user_nsrole(instance, cn, nsRoleFilter, description,
> suffix=None):
> > global test_user_id
> > if cn is None:
> > cn =
