|
On 01/22/2019 09:51 AM, Anuj Borah
wrote:
@Ludwig Krispenz 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
01/22/2019 08:57 AM, Anuj Borah wrote:
@Ludwig Krispenz ,
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 01/21/2019 11:01 PM, William Brown wrote:
>
>> On 21 Jan 2019, at 17:08, Anuj Borah <aborah@xxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
|
