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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
