On 01/22/2019 09:51 AM, Anuj Borah wrote:
@Ludwig Krispenz <mailto: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.
I'll do it once again, but William and I had asked several times for a
doc describing what you want to achieve with these tests, not throwing
other versions of the script and let us figure out what it is meaning.
Now from the bash script it looks like this is not for rolebased acees
but for virtual attributes taken into account when selecting the target.
To check if this is a correct port we would need the contents of the
acivattr.ldif
On Tue, Jan 22, 2019 at 1:48 PM Ludwig <lkris...@redhat.com
<mailto:lkris...@redhat.com>> wrote:
On 01/22/2019 08:57 AM, Anuj Borah wrote:
@Ludwig Krispenz <mailto: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
<mailto: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
<mailto: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
<mailto:389-devel@lists.fedoraproject.org>
> To unsubscribe send an email to
389-devel-le...@lists.fedoraproject.org
<mailto: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
<mailto:389-devel@lists.fedoraproject.org>
To unsubscribe send an email to
389-devel-le...@lists.fedoraproject.org
<mailto: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
