Hi Manuranga, 1. I think you have misunderstood my previous mail. In our security implementation with C4 we are creating an internal role per queue. But in our C5 implementation we are hoping to avoid this and assume that the roles are created in the user store before creating the queue/topic.
2. Answering to your second question, actually from the code when user enabled the global level permission, we handle it as you said. But there should be a way to give those permission in the UI so that user can easily understand. That's why we are giving it in the permission tree. Thanks On Thu, Aug 11, 2016 at 7:13 AM, Manuranga Perera <m...@wso2.com> wrote: > > 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 <saj...@wso2.com> 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: saj...@wso2.com >> Blog: http://sajinid.blogspot.com/ >> Git hub profile: https://github.com/sajinidesilva >> >> Phone: +94 712797729 >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : m...@wso2.com > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sajini De SIlva Senior Software Engineer; WSO2 Inc.; http://wso2.com , Email: saj...@wso2.com Blog: http://sajinid.blogspot.com/ Git hub profile: https://github.com/sajinidesilva Phone: +94 712797729
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
