Hi Dilini, "Considering these facts, can we conclude only the primary super admin (admin/admin) can create roles with Admin permissions?" - Yes. That is the case. However, as you have correctly understood, this only means that the permission "permissions/admin" can only be assigned to a role by the super admin and no other admin user.
"Secondly, although the aggregate of children does not constitute the parent according to the implementation, isn't the behaviour in the functionality the same?" - No, they are not. Consider you have assigned a role(role1, say) the permission '/permissions/admin/' and another role (role2) has all the children of "/permissions/admin/" but not "permissions/admin" itself. Now assume you add a new permission that is not already there. role1 will now have the new permission and role2 will only have the ones you assigned earlier. I hope this is clear. " If we select all the child permissions we allow to create the role and if we select only parent Admin permission which assigns exactly the same set of permissions, we don't allow to create the role." - Following the above explanation, this is by design and hence is logically accurate for* our permission/entitlement model.* Hope this explains the situation. On Fri, Oct 9, 2015 at 12:28 PM, Dilini Gunatilake <[email protected]> wrote: > Hi Damith, > > First of all, I want to clarify what Omindu mentioned regarding his > statement "Only the super admin can create a role with Admin permission". > > In this case I created the new role from a user with default admin role. > Default 'admin' role in the sense, the role that is assigned to the primary > super admin user (admin/admin). Refer [1]. I believe a user with this > 'admin' role can do anything the primary super admin can do. > > I also tried out the same use case from a user with super admin > permission. Permission assigned as in [2]. In both cases, I couldn't create > a role with just admin permission. > > Considering these facts, can we conclude only the primary super admin > (admin/admin) can create roles with Admin permissions? > > Secondly, although the aggregate of children does not constitute the > parent according to the implementation, isn't the behaviour in the > functionality the same? If we select all the child permissions we allow to > create the role and if we select only parent Admin permission which assigns > exactly the same set of permissions, we don't allow to create the role. > This behaviour is contradicting to each other from user's perspective. > Isn't it? > > Regards, > Dilini > > [1] > > > [2] > > > > > On Thu, Oct 8, 2015 at 11:42 AM, Damith Senanayake <[email protected]> > wrote: > >> Since this is the expected behavior and not a bug, I guess we can resolve >> the JIRA [1]. >> >> [1] - https://wso2.org/jira/browse/IDENTITY-3758 >> >> On Thu, Oct 8, 2015 at 11:40 AM, Damith Senanayake <[email protected]> >> wrote: >> >>> Hi Dilini, >>> >>> Suppose you have selected all children of a parent permission is >>> selected (in this case "permissions/admin/configure, >>> permissions/admin/monitor, permissions/admin/login, >>> permissions/admin/manage"). However if you add a fifth child (say >>> "permissions/admin/backup"), that is not assigned to that particular role, >>> whereas if you have selected "permissions/admin", the new permissions will >>> be implicitly added. >>> >>> Since the aggregate of children does not constitute the parent in our >>> permission model, selecting the parent and selecting all its children nodes >>> are two different scenarios, hence this is the expected behavior. >>> >>> HTH, >>> >>> On Tue, Oct 6, 2015 at 9:59 AM, Dilini Gunatilake <[email protected]> >>> wrote: >>> >>>> Hi Omindu, >>>> >>>> What is the difference of giving all the child permissions and parent >>>> admin permission? Is there any difference in the functionality? >>>> >>>> Regards, >>>> Dilini >>>> >>>> On Tue, Oct 6, 2015 at 12:19 AM, Omindu Rathnaweera <[email protected]> >>>> wrote: >>>> >>>>> Hi Dilini, >>>>> >>>>> Only the super admin can create a role with Admin permission, hence >>>>> the exception in your first scenario. In your second scenario, you are >>>>> giving all the child permissions which is different from giving the parent >>>>> Admin permission. >>>>> >>>>> Have a look at the first few lines at *UserRealmProxy::addRole *[1] >>>>> method. In the first scenario, the list of permissions passed to the >>>>> addRole method includes "/permission/admin" (Since 'Admin Permissions' is >>>>> selected) while the second scenario doesn't. In the addRole method, if the >>>>> "/permission/admin" is included in the list of permissions, an exception >>>>> is >>>>> thrown. So this should be the expected behavior. >>>>> >>>>> >>>>> [1] - >>>>> https://github.com/wso2/carbon-identity/blob/master/components/user-mgt/org.wso2.carbon.user.mgt/src/main/java/org/wso2/carbon/user/mgt/UserRealmProxy.java#L869 >>>>> >>>>> Regards, >>>>> Omindu. >>>>> >>>>> >>>>> On Mon, Oct 5, 2015 at 6:05 PM, Dilini Gunatilake <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi IS team, >>>>>> >>>>>> I tried to create a new role logged in from a user with default admin >>>>>> role in MB 3.0.0-ALPHA. When I give permissions as in [1] I get an error >>>>>> as >>>>>> in [2] and couldn't create the role. Please find the full stack trace >>>>>> attached. >>>>>> >>>>>> But, if I assign permissions as in [3], I can successfully create the >>>>>> role. Is this due to a permission issue in the UI? >>>>>> >>>>>> [1] >>>>>> >>>>>> [2] >>>>>> >>>>>> >>>>>> >>>>>> [3] >>>>>> >>>>>> Thank you. >>>>>> Regards, >>>>>> >>>>>> -- >>>>>> >>>>>> *Dilini GunatilakeSoftware Engineer - QA Team* >>>>>> Mobile : +94 (0) 771 162518 >>>>>> [email protected] >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "WSO2 Engineering Group" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout >>>>>> . >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Omindu Rathnaweera >>>>> Software Engineer, WSO2 Inc. >>>>> Mobile: +94 771 197 211 >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Dilini GunatilakeSoftware Engineer - QA Team* >>>> Mobile : +94 (0) 771 162518 >>>> [email protected] >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> >>> >>> *-Damith Senanayake-*+94712205272 >>> >> >> >> >> -- >> >> >> *-Damith Senanayake-*+94712205272 >> > > > > -- > > *Dilini GunatilakeSoftware Engineer - QA Team* > Mobile : +94 (0) 771 162518 > [email protected] > -- *-Damith Senanayake-*+94712205272
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
