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