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
