[MB4] Authorization Model for Message Broker

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[MB4] Authorization Model for Message Broker

Waruna Jayaweera
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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Waruna Jayaweera
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: +94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Himasha Guruge
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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: +94 777459299

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Pamod Sylvester
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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: +94 77 7779495

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Hasitha Hiranya
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 <[hidden email]> 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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: +94 77 7779495



--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Asanka Abeyweera
In reply to this post by Pamod Sylvester
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] "[MB4] Dead Letter Exchange implementation" @architecture

On Fri, Jan 12, 2018 at 9:10 AM, Pamod Sylvester <[hidden email]> 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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: +94 712228648



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Hasitha Hiranya
Hi Asanka,


On Fri, Jan 12, 2018 at 10:27 AM, Asanka Abeyweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: +94 712228648





--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Waruna Jayaweera
In reply to this post by Himasha Guruge
Hi Himasha,
User who create the resource will have permission in all actions for given resource. Other users will  depend on their global permission on given resource type. Resource ownership concept in C5 model haven't been finalized yet. Will check on that as well.

Thanks.
Waruna 

On Fri, Jan 12, 2018 at 7:21 AM, Himasha Guruge <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:+94%2077%20745%209299" value="+94777459299" target="_blank">+94 777459299

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Waruna Jayaweera
In reply to this post by Hasitha Hiranya
Hi Hasitha,

Please refer my comments inline.

On Fri, Jan 12, 2018 at 9:56 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Hasitha Hiranya
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 <[hidden email]> wrote:
Hi Hasitha,

Please refer my comments inline.

On Fri, Jan 12, 2018 at 9:56 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Waruna Jayaweera
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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Hasitha,

Please refer my comments inline.

On Fri, Jan 12, 2018 at 9:56 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: +94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Indika Sampath
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.

On Sun, Jan 14, 2018 at 9:31 AM, Waruna Jayaweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Hasitha,

Please refer my comments inline.

On Fri, Jan 12, 2018 at 9:56 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Indika Sampath
Associate Technical Lead
WSO2 Inc. 
http://wso2.com

Phone: +94 71 642 4744
Blog: http://indikasampath.blogspot.com/


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Authorization Model for Message Broker

Waruna Jayaweera
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 <[hidden email]> 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.

On Sun, Jan 14, 2018 at 9:31 AM, Waruna Jayaweera <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Hasitha,

Please refer my comments inline.

On Fri, Jan 12, 2018 at 9:56 AM, Hasitha Hiranya <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]



Thanks,
Himasha 

On Tue, Jan 9, 2018 at 12:07 AM, Waruna Jayaweera <[hidden email]> wrote:
Hi,
Reattach the missing diagram .

Inline image 1

Thanks,
Waruna 

On Tue, Jan 9, 2018 at 12:00 AM, Waruna Jayaweera <[hidden email]> 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: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Himasha Guruge
Senior Software Engineer 
WSO2 Inc.
Mobile: <a href="tel:077%20745%209299" value="+94777459299" target="_blank">+94 777459299



--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495



--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198




--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: <a href="tel:+94%2071%20325%205198" value="+94713255198" target="_blank">+94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Indika Sampath
Associate Technical Lead
WSO2 Inc. 

http://wso2.com

Phone: <a href="tel:+94%2071%20642%204744" value="+94716424744" target="_blank">+94 71 642 4744
Blog: http://indikasampath.blogspot.com/




--
Regards,

Waruna Lakshitha Jayaweera
Senior Software Engineer
WSO2 Inc; http://wso2.com
phone: +94713255198


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture