Hi Akalanka, I have few questions.
1. How are we authorize user's who connect to broker via JMS client program? In that case we only passing username and password in AMQP URL. User may not assigned to any role at the moment other than default role (Internal/everyone). 2. Is subscribe action meant to create queue/topic as well? or only allow to consume? 3. What is the authorization approach for admin user? Do we allow to proceed any action to any queue/topic? Cheers! On Wed, Feb 24, 2016 at 11:52 AM, Akalanka Pagoda Arachchi < darsha...@wso2.com> wrote: > Hi All, > > Me and Hasitha is planning to revamp the authorization model of MB with > regards to C5 Jaas integration. Previously we had our authorization model > tightly coupled with the registry. > > In a MB use cases, we have to be able to provide authorization to a > hierarchy as below. > > Consider a topic tree *"Sports.Cricket.SL <http://Sports.Cricket.SL>"*. > There are three topics defined here given as 'Sports', 'Sports.Cricket' and > 'Sports.Cricket.SL'. > Each of these topics will have permissions to *subscribe, publish, > browse, purge and delete*. > > We're planning to create a new permission on creation of a topic, named > under the topic. So, for the above case, three permissions will be created > under the given topic names. > Each of these created permission will contains actions for the listed > actions above (subscribe, publish, browse, purge, delete). > > These permission will respect the hierarchy and allow the specified action > if a top level permission is given. For an example, if a user has a > permission 'Sports' with 'subscribe' action, that user will be able to > subscribe to all the three topics given. > > When assigning these permissions to user, there are two approaches we can > take. > > > 1. *Create separate roles, one per each action in each topic. * > > For the above scenario, we will have 5 roles per topic as sub_sports, > pub_sports, browse_sports, purge_sports, delete_sports. > Collectively there will be 15 roles for the three topics listed above. > > Whenever a user has to be given permission to subscribe to a topic, we > can assign the respective role to that user. > > This approach will create a large number of roles in a system where a > large number of topics are available. > > 2. *Create a role per user.* > > Whenever a user has to be given permission to subscribe to a topic, we > can assign the given topic permission with subscribe action to the user's > role. > > Eg: - If a user has to be given permission to subscribe to topic > 'Sports.Cricket', we assign the user's role with permission > 'Sports.Cricket' with action 'subscribe'. > > This approach will create a large number of roles in a system where a > large number of users are available. > > In a typical MB use case, there will be more topics created than the > number of users and therefore we would prefer to use the 2nd approach. > However, assigning a role to a user is not the proper way to utilize roles. > Therefore we would like to know your input on this. > > Thanks, > Akalanka. > > -- > *Darshana Akalanka Pagoda Arachchi,* > *Software Engineer* > *078-4721791* > -- Indika Sampath Senior Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
