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.
>
Isn't this similar to what we are trying to solve with secured helper with
permission?
>
> --
> 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
>
>
--
Regards,
UdaraR
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
