On 01/21/2019 11:01 PM, William Brown wrote:
On 21 Jan 2019, at 17:08, Anuj Borah <[email protected]> wrote:
One small correction here :
using newly created nsUserAccountRole and nsUserAccountRoles ( Will be used
only to create filter role ) , i am creating filter roles only . This is the
confusion here , we should remember filter roles are nothing but entries with
o='something'. I am not touching any user here , but i am creating roles and
these roles are covering the users automatically a Ludwig Krispenzs said
earlier. example-
role=nsUserAccountRole(topo.standalone,'cn=tuser1,ou=People,dc=example,dc=com')
user_props={'cn':'Anuj', 'nsRoleFilter':'cn=*'}
role.create(properties=user_props, basedn=SUFFIX)
In above example just created one filer role which will cover all users having
'cn=*' in 'ou=People'. Here 'cn=tuser1,ou=People,dc=example,dc=com' is nothing
but a filter role which will cover all users having 'cn=*' in 'ou=People'.
Another example as given bellow:
dn: cn=FILTERROLEENGROLE,o=acivattr1,dc=example,dc=com
cn: FILTERROLEENGROLE
nsRoleFilter: cn=*
objectClass: top
objectClass: LDAPsubentry
objectClass: nsRoleDefinition
objectClass: nsComplexRoleDefinition
objectClass: nsFilteredRoleDefinition
This above entry is nothing but filter role entry , which will cover all users
in 'o=acivattr1' which has sub entries that begins with 'cn'. And this is the
property of filter role .
Yes , i must say that newly created nsUserAccountRole and nsUserAccountRoles
which i renamed to nsFilterAccountRole and nsFilterAccountRoles will only
cover filter role as you cant create Filter role and other roles like Manage
role all together . For my porting stuff newly created nsFilterAccountRole and
nsFilterAccountRoles is more than enough because i need filter roles only .
Hope it clears all of your doubts.
So I think the idea of composing this with nsUsers/nsAccount is so that the
nsRoleFilter becomes:
&(objectClass=account)(cn=*)
but this filter would probably match all accounts, to properly test role
based acis you need to have a set of user matching the filter and get
access granted and a set of user not matching the filter and access
rejected.
This way it’s limited to just those types. Else we would have just
“nsFilteredRole” lib389 type (which could be simpler, given that this idea
seems to have caused so much confusion already … :( )
I still think it would be good to see a write of “how it works” by hand, where
you make the role, add the filter, show the roles on the users, then how that
translates to the lib389.
+1
Thanks,
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
_______________________________________________
389-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
