@Ludwig Krispenz <lkris...@redhat.com> The script i have attached in my previous mail was ported from the TET script .
Now i am attaching the main bash script , please check it out. On Tue, Jan 22, 2019 at 1:48 PM Ludwig <lkris...@redhat.com> wrote: > > > On 01/22/2019 08:57 AM, Anuj Borah wrote: > > @Ludwig Krispenz <lkris...@redhat.com> , exactly, Please check attached > script , how it is implemented . > > Filter role and aci combination . > > > But this is not testing role based acis, > > your bind rule always is userdn=...., and you are using the roles attr in > targeting entries. See the admin guide for acis: > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/defining_bind_rules#using_the_roledn_bind_type > > so what you need is an aci with > > allow (search, read) roledn="ldap:///cn=<your role > definition>,dc=example,dc=com" > > > then you need an filterdrole entry : > > cn=<your role definition>,dc=example,dc=com > nsrolefilter: <some filter> > > then you need users matching this filter and users not matching that > filter, and check the results of an ldap operation. > > Please follow the request and do a writeup of what you want to achieve, > before providing new code. > > Ludwig > > > > > > > > On Tue, Jan 22, 2019 at 1:13 PM Ludwig <lkris...@redhat.com> wrote: > >> >> >> On 01/21/2019 11:01 PM, William Brown wrote: >> > >> >> On 21 Jan 2019, at 17:08, Anuj Borah <abo...@redhat.com> 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 -- 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 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 >> > >
acivattr.sh
Description: application/shellscript
_______________________________________________ 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
