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>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
