Hi All, The following changes will be made to the UUF framework in order to archive the above.
- You now have to implement the `Authorizer` interface in order to plug in any type of `Authorizer` you want. `Authorizer` interface will have the following methods: boolean hasPermission(User user, Permission permission); - In order to plug in the `Authorizer`, the `Authorizer` implementation needs to be specified in the `app.yaml` configuration of the particular UUF app. ... # Authorizer for this app authorizer: "org.wso2.carbon.uuf.sample.simpleauth.bundle.api.auth.CaasAuthorizer" ... Please note that if you do not specify this value, the app will not have an `Authorizer` and will return `false` every time the `hasPermission()` method is called. - Instead of the `User` interface, we now have introduced a concrete `User` class. On Wed, May 3, 2017 at 10:34 PM, Rasika Perera <[email protected]> wrote: > Hi Sajith, > > I am +1 to allow custom authorizers. But not bit convinced with the reason > provided. > > Java allows non-serializable properties on the objects with "transient" > keyword. At the time of deserialize these properties will be in default > values (i.e. objects will be null). Then you can override "readResolve()" > method to fetch & assign the current state of the system for those > properties. > > Best Regards, > Rasika > > On Wed, May 3, 2017 at 10:47 AM, SajithAR Ariyarathna <[email protected]> > wrote: > >> Hi All, >> >> We are in the process of introducing an extensible authorizer for Carbon >> UUF. >> >> At the moment authorization is done via the org.wso2.carbon.uuf.spi.au >> th.User interface [1]. When creating an user session, implementation of >> the User interface (e.g. CaasUser [2]) should be passed. The main >> drawback of this approach is, the logic in the hasPermission() method >> has to be serializable. Usually this is difficult to achieve because in >> order to evaluate permissions one might need to access some user management >> services (e.g. Realm Service) which cannot be serialized. Hence moving the >> hasPermission() method out of the User class and allowing to plug-in a >> custom authorizer would be a better approach. >> >> WDYT? >> >> [1] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/compo >> nents/uuf-core/src/main/java/org/wso2/carbon/uuf/spi/auth/User.java#L28 >> [2] https://github.com/wso2/carbon-uuf/blob/v1.0.0-m14/sampl >> es/osgi-bundles/org.wso2.carbon.uuf.sample.simple-auth.bundl >> e/src/main/java/org/wso2/carbon/uuf/sample/simpleauth/bundle >> /CaasUser.java >> >> Thanks. >> -- >> Sajith Janaprasad Ariyarathna >> Senior Software Engineer; WSO2, Inc.; http://wso2.com/ >> <https://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With Regards, > > *Rasika Perera* > Senior Software Engineer > LinkedIn: http://lk.linkedin.com/in/rasika90 > > <http://wso2.com/signature> > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Best Regards, *Vidura Nanayakkara* Software Engineer Email : [email protected] Mobile : +94 (0) 717 919277 Web : http://wso2.com Blog : https://medium.com/@viduran <http://wso2.com/> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara <http://wso2.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
