1. Instead of creating a role dynamically, which was a hack, we can use owner concept 2.
My idea was, since resources are hierarchical, we don't need a special global level permissions Eg: jmstopic:/news/sports will have add, browse, delete,.. jmstopic:/ will also have the same action set, but due to hierarchy it acts as the global level automatically. In this model 'manager' will just be a role with correct permission to that root path. We need to discuss if this is the correct approach with Prabath at el. On Wed, Aug 10, 2016 at 2:37 PM, Sajini De Silva <[email protected]> wrote: > Hi, > > MB security model with C4 has some limitations and issues. In our current > model we create an internal role for every queue and assign Subscribe and > Publish permission for that role. When a JMS client subscribes to a queue > which is not created yet, we create that internal role for that queue and > assign permission to that role. Then assign that role to the the current > user. In this way we guarantee only the user who created the queue will > have permission to subscribe or publish other than admin user. > > But the drawback of this model is that we create role for every queue and > topic and there can be many such roles when the number of queues/topics > increases. > > As a solution to this issue we came up with a new security model. In this > case we do not create any internal roles inside MB. User has to give > permission from UI before he subscribes to a queue. If the user still wants > to subscribe to a queue which is not created yet, then we introduce two > common roles which will be created at the startup of the server. Those are > SUBSCRIBER role and PUBLISHER role. The SUBSCRIBER role can subscribe to > any queue/topic and PUBLISHER role can publish to any queue/topic. > Therefore a user who has the role SUBSCRIBER can subscribe to any > queue/topic and create even though the queue is not created yet. > > In the permission tree model also we are going to do some modifications. > Current permission tree model in C5 for queues and topics will be as > follows. > > We have changed the topic permissions by adding Browse, Purge, > Subscription Disconnect permission and removing Detail permission. Browse, > Purge and Subscription Disconnect permissions will only affect if the topic > has durable subscriptions. > > In our previous model other than these global permission, we had Subscribe > and Publish permission at queue level. It came in to our consideration that > other than those two permissions Browse, Purge, Delete and Subscription > Disconnect permissions should also should be configurable per queue. > Therefore we are adding these four additional permissions to each > queue/topic when it is created. Those can be edited if needed. > > Also we are planning to create another Manager role at the startup of the > server which has all the queue and topic related permissions. Any user who > has this manager role can add,delete, browse, purge or disconnect > subscriber for any queue. Also can browse any subscriptions. > > Other permissions in the permission tree will remain as same as in C4. > > Thanks > > -- > Sajini De SIlva > Senior Software Engineer; WSO2 Inc.; http://wso2.com , > Email: [email protected] > Blog: http://sajinid.blogspot.com/ > Git hub profile: https://github.com/sajinidesilva > > Phone: +94 712797729 > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- With regards, *Manu*ranga Perera. phone : 071 7 70 20 50 mail : [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
