@Ludwig Krispenz <lkrispen(a)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 <lkrispen(a)redhat.com> wrote:
On 01/22/2019 08:57 AM, Anuj Borah wrote:
@Ludwig Krispenz <lkrispen(a)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...
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 <lkrispen(a)redhat.com> wrote:
>
>
> On 01/21/2019 11:01 PM, William Brown wrote:
> >
> >> On 21 Jan 2019, at 17:08, Anuj Borah <aborah(a)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(a)lists.fedoraproject.org
> > To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
>