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 3320919blog: **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
