Hi All, I have a concern with the '(1) Session based approach'.
As per our Group implementation, grouping is depending on the permissions and roles. So when group is shared with a user, the particular sharing role will assigned to the user and then we need to manipulate UI bits for grouped devices, based on the permissions which user got though the role. So it will make inconsistency in UI elements as Rasika explained more frequently. Therefore it is needed to implement more consistent way to check permissions rather than using session based approach. As Dilan explained '(3) Web APIs to call user management core' could have significant impact on performance and managing and implementing caching coherency is an extra effort for this approach, I'm seeing '(2) OSGI Calls from back end javascript layer to user management core' would be a possible solution for this. However if we could utilize permission check cache(if exists) at the user-core level as Rasika suggested, we can write logic to update that cache when ever grouping related operations (add/remove devices, change sharing, create/delete groups) are performed. Also if we could implement Rasika's suggestion in java level as an OSGi service with logic to update cache when required, we can reuse the same cache for our APIs and it would help to improve the performance significantly. So I'm +1 for the Rasika's suggestion with logic to update cache when ever needed. Thanks & Regards, /charithag On Thu, Sep 8, 2016 at 8:22 AM, Dilan Udara Ariyaratne <[email protected]> wrote: > Hi Rasika, > > For third-party UIs expecting to use our web APIs, we will also have to > expose an unprotected web API for login-time authentication and login > authorization check. > > And when it comes to performance concerns, > > [1] Session based approach - "YES", in the session based approach we will > have consistency issues in between Backend and UI, if permissions of the > user get updated during > the valid time of an active session. Yet IMO, this approach stands out as > the fastest permission checking approach in comparison to other methods > that you mention and > one counter-argument that we could make for inconsistency issues is that > this kind of an inconsistency could happen very rarely as permission level > changes for roles > is not that frequent. And even if that happens, since we anyway check the > most updated state of a permission at API layer, we always have the right > level of security guaranteed from our backend. > > WDYT? > > [2] OSGI Calls from backend javascript layer to user management core - > This stands out as the second fastest since this is an in-JVM call and not > a network call to user management OSGI component. > Yet I believe we should optimize our backend javascript wrapper to support > multiple permission checks in one go, so that it minimizes the > reinitialization of required user management beans for each > permission check. What I exactly mean is to change > .isAuthorized(permission) >>>> .isAuthorized(List<String> permissions), so > that all the permissions to be checked for a page or unit > could be verified in one go. > > [3] Web APIs to call user management core - This stands out to be the > slowest as it requires a network call to an API from the UI to do an > authorization check. > Even here I believe that we should support a request body of multiple > permissions, so that we can verify the level of authorization of a user for > a page or unit in one go and most importantly > one network call, instead of a few. > > WDYT? > > Cheers, > Dilan. > > *Dilan U. Ariyaratne* > Senior Software Engineer > WSO2 Inc. <http://wso2.com/> > Mobile: +94766405580 <%2B94766405580> > lean . enterprise . middleware > > > On Thu, Sep 8, 2016 at 5:17 AM, Rasika Perera <[email protected]> wrote: > >> Hi All, >> >> With the current migration of EMM webapp from UUF v0.1 to v0.2 (jaggery >> based implementation) we are trying to standardize the permission check for >> UI bits. We need to check permissions for “pages” level as well as granular >> to the “units” level. For example; show/hide a button based on UI >> permission. Also should notice that these permissions are not unique to the >> front-end, thus can be directly mapped into the respective back-end osgi >> services. For example; device enroll permission will be checked on the >> enrollment page(front-end), as well as the inside the respective enrollment >> osgi service(back-end). >> >> And also there’s a requirement that any third-party application should be >> able to write their own UI based on our web apis. Hence we are expecting to >> expose isAuthorized() via JAX-RS too. SOAP clients will be able to directly >> call admin-service. >> >> [image: Inline image 1] >> >> >> >> As per the diagram, when a EMM web app receives a page render request >> from the browser, UUF will execute the the method isAuthorized() at the >> back-end JavaScript layer. JavaScript will include the “carbon” jaggery >> module which will import the RealmService OSGi service. Using RealmService >> we can invoke the Authorizer.isRoleAuthorized(). >> >> Whenever, third-party application requests for a permission check via >> EMM-API(JAX-RS), final result should be given invoking same >> Authorizer.isRoleAuthorized() method. >> >> One concern on this design was how to improve the *performance* of OSGi >> calls per permission check. One such suggestion is to retrieve all >> permissions for the current user and persist it on the “session”. IMO this >> would results some unforeseen issues and permission update on the backend >> will not immediately applied on the already logged users(eg. longer session >> timeouts). For example: users will still see the action buttons when >> clicked on it, it will return permission error. On the other hand, managing >> caching coherency is an extra effort for this approach. My suggestion is to >> utilize the permission check cache(if exists) at the user-core level which >> would be consistent across the platform. >> >> WDYT? >> >> @DS/UUF Team: I hope we need the similar permission check feature with >> the {{permission}} handlebar helper. >> >> -- >> With Regards, >> >> *Rasika Perera* >> Software Engineer >> LinkedIn: http://lk.linkedin.com/in/rasika90 >> >> [image: wso2-signature-general.png] <https://wso2.com/signature> >> >> WSO2 Inc. www.wso2.com >> lean.enterprise.middleware >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Charitha Goonetilleke* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 77 751 3669 <%2B94777513669> Twitter:@CharithaWs <https://twitter.com/CharithaWs>, fb: charithag <https://www.facebook.com/charithag>, linkedin: charithag <http://www.linkedin.com/in/charithag> <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
