Hi Waruna, I think flat permission would be easier to understand rather going more granularity. Please look at the [1] which is actual operations comes from the broker core in the MB 3.x.x. It has only,
CREATE - exchange or queue BIND PUBLISH CONSUME BROWSE UNBIND DELETE PURGE When you design authorization model, consider all operation. I am not sure how this going to be visualized in the latest user core or any related component. But you could have a proper design on what should be on queue/topic level and what should on management console level. [1] https://github.com/wso2/carbon-business-messaging/blob/master/components/andes/org.wso2.carbon.andes.authorization/src/main/java/org/wso2/carbon/andes/authorization/service/andes/AndesAuthorizationPlugin.java#L143 Cheers! On Sun, Jan 14, 2018 at 9:31 AM, Waruna Jayaweera <[email protected]> wrote: > Hi Hasitha, > Here are the resources and actions came up with to which user groups will > get permissions. > > Queue > - create > - consume > - delete > > Exchange > - bind > - unbind > - create > - delete > > BindingKey > - publish > > Users will need consume permissions for queues and as for topics they need > both create and consume permissions. So system will not depend on any other > exchange type as to authorize users based on their permissions. > For hierarchical topics, user need relevant permission at lease one > matching binding key on given topic name. > > Thanks, > Waruna > > On Sun, Jan 14, 2018 at 7:16 AM, Hasitha Hiranya <[email protected]> > wrote: > >> Hi Waruna, >> >> Thank You. That explains. >> Another side question is permission model for hierarchical topics. In a >> way, as topic is a concept, we will have to authorise user when the queue >> created on behalf of the subscriber binds to the exchange. I would suggest >> following. >> >> >> temp queue creating done for a topic subscription need no permission >> and system will do that >> >> when that queue binds to a topic check if user on subscriber channel >> has permission to subscribe. >> >> Thoughts? >> >> Thanks >> >> >> On Fri, Jan 12, 2018 at 5:22 PM, Waruna Jayaweera <[email protected]> >> wrote: >> >>> Hi Hasitha, >>> >>> Please refer my comments inline. >>> >>> On Fri, Jan 12, 2018 at 9:56 AM, Hasitha Hiranya <[email protected]> >>> wrote: >>> >>>> Hi Waruna, >>>> >>>> In MB 3.1.0 authentication model, we gave publish/subscribe permission >>>> automatically to the user who created the queue. >>>> Are we having same concept here as well? >>>> >>> >>> Yes. User will be owner of that resource and he will have all >>> permissions. We also give grant permission to queue owner so he will able >>> to grant those actions to other users on his queue. >>> >>>> Topic is a concept and transport will have nothing like "create a >>>> topic". It will be an internal queue creation. So it will not be applicable >>>> to topic. >>>> Are we planning to have a separate action called "create" queue and >>>> define a permission other than publish/subscribe? >>>> >>>> Yes. I need to finalize the queue actions and reply soon. >>> >>>> BTW, no:3 is bit confusing to me. >>>> >>> >>> We may need to provide all permissions to given resource type ex. admin >>> group can publish any queue. For that will use same permission structure >>> with global level permission on resource type.(ex.Queue) >>> >>>> >>>> Thanks >>>> >>> >>> Thanks, >>> Waruna >>> >>>> >>>> >>>> On Fri, Jan 12, 2018 at 9:10 AM, Pamod Sylvester <[email protected]> >>>> wrote: >>>> >>>>> Hi Waruna, >>>>> >>>>> In this case how will we handle messages which are in DLC ? >>>>> >>>>> Are we going to give the option to subscribe to DLC ? (currently we >>>>> have restricted it). However, that will be a drawback given the queue >>>>> owner >>>>> will not have access to it's own messages which are in the DLC >>>>> >>>>> Thanks, >>>>> Pamod >>>>> >>>>> On Fri, Jan 12, 2018 at 7:21 AM, Himasha Guruge <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Waruna, >>>>>> >>>>>> Have we decided which permissions will be allocated for a user by >>>>>> default when creating a queue/topic? Are we going to consider ownership >>>>>> concept for this, that was discussed in C5 permission model? [1] >>>>>> >>>>>> >>>>>> [1] https://docs.google.com/document/d/1yosWL_kTxUWFukcoU7DtrtZd >>>>>> RuiK0ghySs96u4lfUHU/edit#heading=h.81aqdsft1abw >>>>>> >>>>>> Thanks, >>>>>> Himasha >>>>>> >>>>>> On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> Reattach the missing diagram . >>>>>>> >>>>>>> [image: Inline image 1] >>>>>>> >>>>>>> Thanks, >>>>>>> Waruna >>>>>>> >>>>>>> On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Message broker requires authorization model to access control of >>>>>>>> resources like Topics/Queues based on user groups . This is to provide >>>>>>>> the >>>>>>>> initial design for $Subject. >>>>>>>> Example use case would be as follows. We have three user groups ( >>>>>>>> roles) A , B and manager and two topics T1 and T2. We need to restrict >>>>>>>> users in group as below. >>>>>>>> >>>>>>>> 1. T1 can be subscribed by only A and publish by only B >>>>>>>> 2. T2 can be subscribed by only B and publish by only A >>>>>>>> 3. Manager users can subscribe and publish to any topic but >>>>>>>> only subscribe queue. >>>>>>>> >>>>>>>> Following entities can be identified. >>>>>>>> >>>>>>>> *User groups:* A ,B and manager >>>>>>>> *Resources *: T1 and T2 >>>>>>>> *Resource Groups *: Topic, Queue >>>>>>>> *Actions*: subscribe, publish,view etc. >>>>>>>> *Permission*: resource+actions >>>>>>>> >>>>>>>> We can represent the permissions using binary form mappings with >>>>>>>> resource and user group. These permissions can be defined per resource >>>>>>>> or >>>>>>>> globally as well. >>>>>>>> >>>>>>>> *Per Resource* >>>>>>>> >>>>>>>> Resource >>>>>>>> >>>>>>>> User Group >>>>>>>> >>>>>>>> Actions >>>>>>>> >>>>>>>> Permission >>>>>>>> >>>>>>>> publish >>>>>>>> >>>>>>>> subscribe >>>>>>>> >>>>>>>> T1 >>>>>>>> >>>>>>>> A >>>>>>>> >>>>>>>> 0 >>>>>>>> >>>>>>>> 1 >>>>>>>> >>>>>>>> 01 >>>>>>>> >>>>>>>> T2 >>>>>>>> >>>>>>>> B >>>>>>>> >>>>>>>> 1 >>>>>>>> >>>>>>>> 0 >>>>>>>> >>>>>>>> 10 >>>>>>>> >>>>>>>> *Global Permission* >>>>>>>> >>>>>>>> Resource Type >>>>>>>> >>>>>>>> User Group >>>>>>>> >>>>>>>> Actions >>>>>>>> >>>>>>>> Permission >>>>>>>> >>>>>>>> publish >>>>>>>> >>>>>>>> subscribe >>>>>>>> >>>>>>>> Topic >>>>>>>> >>>>>>>> admin >>>>>>>> >>>>>>>> 1 >>>>>>>> >>>>>>>> 1 >>>>>>>> >>>>>>>> 11 >>>>>>>> >>>>>>>> Queue >>>>>>>> >>>>>>>> admin >>>>>>>> >>>>>>>> 1 >>>>>>>> >>>>>>>> 0 >>>>>>>> >>>>>>>> 10 >>>>>>>> >>>>>>>> >>>>>>>> Permission will be stored in the database similarly as of [1]. >>>>>>>> Following >>>>>>>> figure shows the proposed implementation for $subject. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Connection handler can fetch the mb resource permissions mappings >>>>>>>> from database and user groups information from underlying user store >>>>>>>> manager. Authorized users can add permissions to groups using >>>>>>>> permission >>>>>>>> api. Each resource can have own way of handling permission. As an >>>>>>>> example >>>>>>>> in hierarchical topic scenario, if given user group has permission to >>>>>>>> top >>>>>>>> level topic, will be granted the permission to lower level topic >>>>>>>> structure >>>>>>>> as well. >>>>>>>> >>>>>>>> This is the initial design for permission model and We will >>>>>>>> schedule a design review to further discussion .Your suggestions are >>>>>>>> highly >>>>>>>> appreciated! >>>>>>>> >>>>>>>> [1] [Architecture] [APIM][C5] API Manager >>>>>>>> entities(APIs/Applications/Docs etc..) permission model and group >>>>>>>> sharing. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Waruna >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> >>>>>>>> Waruna Lakshitha Jayaweera >>>>>>>> Senior Software Engineer >>>>>>>> WSO2 Inc; http://wso2.com >>>>>>>> phone: +94713255198 <+94%2071%20325%205198> >>>>>>>> http://waruapz.blogspot.com/ >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> Waruna Lakshitha Jayaweera >>>>>>> Senior Software Engineer >>>>>>> WSO2 Inc; http://wso2.com >>>>>>> phone: +94713255198 <+94%2071%20325%205198> >>>>>>> http://waruapz.blogspot.com/ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Himasha Guruge >>>>>> Senior Software Engineer >>>>>> WS*O2* *Inc.* >>>>>> Mobile: +94 777459299 <077%20745%209299> >>>>>> [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Pamod Sylvester * >>>>> >>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >>>>> cell: +94 77 7779495 <+94%2077%20777%209495> >>>>> >>>> >>>> >>>> >>>> -- >>>> *Hasitha Abeykoon* >>>> Associate Technical Lead; WSO2, Inc.; http://wso2.com >>>> *cell:* *+94 719363063* >>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> Waruna Lakshitha Jayaweera >>> Senior Software Engineer >>> WSO2 Inc; http://wso2.com >>> phone: +94713255198 <+94%2071%20325%205198> >>> http://waruapz.blogspot.com/ >>> >>> >> >> >> -- >> *Hasitha Abeykoon* >> Associate Technical Lead; WSO2, Inc.; http://wso2.com >> *cell:* *+94 719363063* >> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >> >> > > > -- > Regards, > > Waruna Lakshitha Jayaweera > Senior Software Engineer > WSO2 Inc; http://wso2.com > phone: +94713255198 <+94%2071%20325%205198> > http://waruapz.blogspot.com/ > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Indika Sampath Associate Technical Lead WSO2 Inc. http://wso2.com Phone: +94 71 642 4744 Blog: http://indikasampath.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
