Hi Indika, Thanks for the suggestion . I have initially thought of flat permission model as well. But we used resources,permission model since it has decoupling with message broker resources. If you use flat permissions then all permissions will bind to one broker resource. As an example if we need create queue and create exchange as to be two different permissions, flat permission model will not be compleax. Other reason was to have common permission concept across the products.( ex.apim uses resource permission concept for authorize apis,api docs etc.)
In MB4 we have resource permissions to authorize queue/topic level permissions and resource-group-permissions to model management console level permissions. Thanks, Waruna On Sun, Jan 14, 2018 at 10:32 PM, Indika Sampath <[email protected]> wrote: > 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 <+94%2071%20642%204744> > Blog: http://indikasampath.blogspot.com/ > > -- Regards, Waruna Lakshitha Jayaweera Senior Software Engineer WSO2 Inc; http://wso2.com phone: +94713255198 http://waruapz.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
