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
