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
