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? 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?
BTW, no:3 is bit confusing to me. Thanks 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 > -- *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
