Guys, please don't get confused, the above meeting notes I posted above (5/10 3:19pm) are from a discussion we had long time back, where we basically said we got to rethink and redo our permission model.
I think Sameera will post today's meeting notes. On Tue, May 10, 2016 at 5:49 PM, Manuranga Perera <[email protected]> wrote: > Java is only a single case (maybe even a special case). But we should have > a plug-able list of such schemes. The strings should be qualified with the > scheme name. > > Eg: > java permission string "java:/org/wso2/kernal/Server/shutdown" with > action "execute" > jms permission string "jms:/sports/cricket" with actions "publish", > "subscribe", "browse", "purge", "delete" > ect ... > > On Tue, May 10, 2016 at 6:17 AM, Akalanka Pagoda Arachchi < > [email protected]> wrote: > >> Hi All, >> >> In the proposed C5 permission model it seems like it is mainly focused on >> java code level permissions. >> >> Quoting from above - "ii. Java method - FQCN + Operation name" >> >> This will mean, that permissions are bound to an operation in a class. >> However, in MB scenario, permissions are widely used to authorize >> publish/subscribe in queues/topics. >> >> As an example, consider a hierarchical topic we have named >> 'sports/cricket'. >> >> Here, a person who has permissions to publish/subscribe to top level >> topic 'sports', will have permissions to publish/subscribe to the leaf >> level as well. >> >> What we had in mind for C5 permission model for such scenarios is >> something like below. >> >> Permission name = topic name >> Operations = publish, subscribe, browse, purge, delete .etc >> >> So we would like to create two permissions named 'sports' and >> 'sports/cricket' and authorize using those. So we would not be using the >> FQCN for this. >> >> Can we still use the proposed model to achieve this? >> >> Thanks, >> Akalanka. >> >> On Tue, May 10, 2016 at 3:19 PM, Johann Nallathamby <[email protected]> >> wrote: >> >>> Notes from a previous meeting on permission model. >>> >>> *Current Permission Model* >>> >>> 1. Permissions in C4 are stored as hierarchical strings. E.g. >>> "/permission/admin/configure/users" >>> 2. The permissions required for admin services are specified in >>> services.xml, at service level or operation level >>> 3. Permission required to show UI menu items are specified in >>> component.xml >>> 4. The permission tree of all available permissions are stored in >>> registry and used to show the 5. permission tree for role-permission >>> assignment in user-mgt UI >>> 5. Permission assignments for roles are stored user-mgt DB. >>> >>> *Problems with the C4 Model* >>> >>> 1. Developers don’t use the model properly mainly due to lack of care. >>> 2. This leads to too many coarse grained permissions. That is a single >>> permission allows to do lots of things in the server. >>> 3. Also given a permission one can’t say what all actions can be carried >>> out by a user who has that permission. >>> 4. The permission string is statically bound to the code that is >>> executing it. One has to decide in advance what the permission string must >>> be. This not applicable for all the scenarios, at least we can come up with >>> hypothetical scenarios. >>> 5. We only consider the resource and action currently. We don’t consider >>> the context. E.g. a particular user can be performing a particular action >>> on a particular resource, either that belongs to him, belongs to his tenant >>> or belongs to a different tenant. This ‘ownership’ aspect could be captured >>> under context. target = resource + context. >>> 6. Carbon servers in a deployment must share the data model for >>> authorization on the application side. This assumption has drawn lot of >>> negative criticism. When it comes to an ideal deployment this assumption >>> cannot hold true due to security reasons. On the other hand the benefit of >>> having it this way at least for carbon servers is the performance. >>> 7. The way we store permission assignments for roles in the DB is not >>> efficient. Currently permissions are stored as flat strings, and then for >>> evaluation a tree is built. Building a tree from the list of those flat >>> strings are not efficient. >>> >>> *Proposed changes for C5* >>> >>> 1. Don’t have static permission strings. The permission will be derived >>> from the context. Context will depend on Subject, resources, action, method >>> parameters and other environmental attributes that are available. >>> >>> We will need to define multiple syntaxes to define a permission. For >>> example, >>> i. Rest resource - URI + Http Action >>> ii. Java method - FQCN + Operation name >>> iii. SOAP operation - Service Name + Operation Name >>> >>> The only annotation which we will define above a method is >>> checkPermission which says whether to do authorization or not for the >>> method. >>> >>> 2. No assumption of a shared data model anymore. What will be provided >>> is a authorization API as a OSGi service. The implementation will decide >>> whether to do a in-JVM call or remote HTTP call to IS based on some >>> configuration parameter. Authentication for the remote API could be mutual >>> SSL. >>> >>> *How is XACML related to all this?* >>> >>> XACML is a very powerful language which can be used for this purpose. >>> However its still at very early stages of adoption. It is not industrial >>> grade yet. Also not many tools to support writing XACML policies either. >>> Current support in IS is also minimal. With the proposed model of >>> authorization XACML policy based authorization also can be easily supported >>> by plugging in a XACML based authorization module. Also context based >>> authorization has wide usage and XACML is considered a language that can >>> support writing context aware policies. >>> >>> Thanks, >>> Johann. >>> >>> On Tue, Apr 19, 2016 at 7:13 PM, Manuranga Perera <[email protected]> wrote: >>> >>>> I think Azeez and Sameera are talking about 2 orthogonal problems: >>>> >>>> A) How to derive permission string >>>> >>>> Solution 01 - Via Annotation >>>> Solution 02 - From method's fully qualified name >>>> >>>> B) What is protected by the permission >>>> >>>> Model 1 - Block of code >>>> Model 2 - A resource (eg: Topic) >>>> >>>> >>>> On Tue, Apr 19, 2016 at 3:38 AM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> Model 2 is basically saying every operation has to be represented as a >>>>> resource and then use resource permissions. IMO, that is not a very good >>>>> model because representing every operation as a resource is not natural. >>>>> In >>>>> addition, if you take Java Security, they have a model for securing code >>>>> blocks. That is at the lowest level, IMO. At the next level, I think we >>>>> need a model to specify who can do what at the business logic level (Users >>>>> with role user-admin-foo, can add users to the user group foo). The next >>>>> level would be to specify who could invoke operations. e.g. users with >>>>> add-user permission can call the addUsersToGroup operation. So, if a >>>>> someone needs to add a user to group foo, he should have the permissions >>>>> to >>>>> call the addUsersToGroup operation, as well as permissions to add the user >>>>> to the foo group (if applicable). So I prefer model 1. >>>>> >>>>> Azeez >>>>> >>>>> On Tue, Apr 19, 2016 at 11:24 AM, Ramith Jayasinghe <[email protected]> >>>>> wrote: >>>>> >>>>>> Solution 2 seems too rigid. Why? my argument is there could be >>>>>> scenarios more than one functionality ( / method) in a product could >>>>>> require same functionality. >>>>>> if we use class names, things become complicated and cluttered isn't >>>>>> it? thoughts? >>>>>> >>>>>> On Tue, Apr 19, 2016 at 10:02 AM, Sameera Jayasoma <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> The purpose of this meeting was to brainstorm the new permission >>>>>>> model for Carbon 5. This mail contain the summary of the meeting. We >>>>>>> haven’t finalized anything yet. >>>>>>> >>>>>>> During the meeting we discussed on service permissions and resource >>>>>>> permissions. Service permissions are applied to micro services. These >>>>>>> services could be admin services or product specific services. Resource >>>>>>> permissions applies to all the resources in our platform. E.g Registry >>>>>>> resource, Topic, Queues etc. >>>>>>> >>>>>>> Let me try to explain the difference using an example. Consider the >>>>>>> operation “addUserToGrop” in “UserMgtService”. Here we can define >>>>>>> permission at different levels. A user Bob can invoke this method, but >>>>>>> Bob >>>>>>> cannot add users to group Foo. Granting privileges to invoke this method >>>>>>> can be done via service permissions. Restricting Bob from adding user to >>>>>>> group Foo can be done via resource permissions. >>>>>>> >>>>>>> A permission has a name and optional list of actions. There are >>>>>>> permissions with just the name and they are usually called named >>>>>>> permission. Either we give users named permissions or we don’t. Above >>>>>>> mentioned service permissions are named permissions. E.g. Either we >>>>>>> allow >>>>>>> user to invoke the addUserToGroup method or we don’t. There are no >>>>>>> actions >>>>>>> associated with this permission. But for resource permissions , there >>>>>>> are >>>>>>> associated actions. E.g. Registry resources can be added, deleted, >>>>>>> updated >>>>>>> etc. >>>>>>> >>>>>>> >>>>>>> *Declaring Permissions.*We discussed two ways to declare required >>>>>>> permissions in services. >>>>>>> >>>>>>> *Solution 01* >>>>>>> >>>>>>> @RequirePermission(“manage/users”) >>>>>>> public class UserMgtService { >>>>>>> @RequirePermission(“add-user”) >>>>>>> public void addUserToGropu(User user, String groupName) { >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> This is exactly same as Carbon 4 model. Permissions required invoke >>>>>>> a service is declared in the services.xml. With microservices based >>>>>>> services we can declare required permission with annotations. >>>>>>> >>>>>>> *Solution 02* >>>>>>> >>>>>>> @Secure >>>>>>> public class UserMgtService { >>>>>>> public void addUserToGropu(User user, String groupName) { >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Here we calculate the permission string using the classname and the >>>>>>> method name. E.g. >>>>>>> org.wso2.carbon.identity.mgt.UserMgtService.addUser. These service >>>>>>> permission can be checked with an microservice interceptor. >>>>>>> >>>>>>> There are pros and cons of both of these methods. We need to discuss >>>>>>> and come to a conclusion soon. >>>>>>> >>>>>>> Also we need to figure out how to declare resource permissions. >>>>>>> >>>>>>> Thanks, >>>>>>> Sameera. >>>>>>> >>>>>>> -- >>>>>>> Sameera Jayasoma, >>>>>>> Software Architect, >>>>>>> >>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>> email: [email protected] >>>>>>> blog: http://blog.sameera.org >>>>>>> twitter: https://twitter.com/sameerajayasoma >>>>>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>>>>> Mobile: 0094776364456 >>>>>>> >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ramith Jayasinghe >>>>>> Technical Lead >>>>>> WSO2 Inc., http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> E: [email protected] >>>>>> P: +94 772534930 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Afkham Azeez* >>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>> * <http://www.apache.org/>* >>>>> *email: **[email protected]* <[email protected]> >>>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>> <http://twitter.com/afkham_azeez> >>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>> >>>>> *Lean . Enterprise . Middleware* >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Technical Lead & Product Lead of WSO2 Identity Server >>> Governance Technologies Team >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Darshana Akalanka Pagoda Arachchi,* >> *Software Engineer, WSO2* >> *+94777118016 <%2B94777118016>* >> >> _______________________________________________ >> 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 > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Technical Lead & Product Lead of WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
