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
