Hi Asanka,
On Fri, Jan 12, 2018 at 10:27 AM, Asanka Abeyweera <[email protected]> wrote: > Hi Pamod, > > With the new model[1] we are planning to implement, dead letter queue will > be similar to a normal queue. Therefore It will be possible to subscribe to > a dead letter queue. Authorization will be managed similarly to how we do > with normal queues, i.e. admins can alter subscribing permissions depending > on the requirement. > +1 for the approach. Only the difference of a Dead letter queue will be 1. No publishers can publish to that queue. 2. It can be only bound to direct exchange (considered as a queue) (binding is done OOB) 3. No create permissions. It is created OOB. > > [1] "[MB4] Dead Letter Exchange implementation" @architecture > > 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> >> > > > > -- > Asanka Abeyweera > Associate Technical Lead > WSO2 Inc. > > Phone: +94 712228648 > Blog: a5anka.github.io > > <https://wso2.com/signature> > -- *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
