On Sun, May 4, 2014 at 8:18 PM, Gayan Gunawardana <[email protected]> wrote:
> Hi Chan, > > As I understood situation is like this, > > case 01: "write access is not provided" means read only LDAP or user store > cannot be modified, in that case we will create necessary roles internally > in order to function the system properly and we are not going to create any > users internally[1]. > Is it possible for us to create internal users as well? If so - Admins can provision to test users within our system safely. > > case 02: If write access is provided, we can create both users and roles > in the given user store (typically read/write LDAP) > > > In case 02 disable internal roles and case 01 only enable internal roles. > (Please correct me if I am wrong) > In case 02 -we can make it optional to disable internal roles. For example - if the admin wants to create a group without worrying about user store roles to dynamically provision a policy. If an external user store is configured -internal roles creation become optional. If not Internal role creation is enabled. We can have a json config about the preference in case of external user store. WDYT? > > [1]https://docs.wso2.org/display/IS460/Configuring+Primary+User+Stores > > > On Sun, May 4, 2014 at 2:58 PM, Chan <[email protected]> wrote: > >> Hi folks, >> I am currently working on the $subject for EMM 1.1.0 release. EMM 1.0.0 >> used the default jaggery carbon module and internal user and group modules >> to solve the UM aspect. Below are some of the issues we have - >> >> - Coupling to the email >> - Roles creation is ambiguous (for example not write access to the >> User store) >> - User creation (no write access to User store) >> - Not supporting secondary User store >> - XACML usage >> >> The new UserModule aims to solve the above problems. There will be a >> config file that has configs whether to enable internal role and user >> creation. If enabled and write access is not provided - we create users and >> roles internally. If disabled we will remove those elements from UI and >> disable operations from the API. The new UserModule will always pass the >> carbon user object [1]. All the static operations that will be used will be >> under the UserModule. >> >> The new UserModule will remove XACML for permission. Even though we used >> XACML for permissions on operations in the last version (1.0.0) we didn't >> see a real advantage of it for the features we had. For 1.1.0 we discussed >> to remove XACML and use a database table to handle permissions for roles. >> However -we'll be incorporating XACML in the future releases (1.2.0 >> perhaps) and will be giving the real advantage of it (eg:- time based >> permissions, write your own XACML in EMM UI). >> >> Cheers~ >> >> [1] - >> https://github.com/wso2/jaggery-extensions/blob/master/carbon/module/scripts/user/user.js >> >> >> -- >> Chan (Dulitha Wijewantha) >> Software Engineer - Mobile Development >> WSO2Mobile >> Lean.Enterprise.Mobileware >> * ~Email [email protected] <[email protected]>* >> * ~Mobile +94712112165 <%2B94712112165>* >> * ~Website dulitha.me <http://dulitha.me>* >> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >> *~Github @dulichan <https://github.com/dulichan>* >> *~SO @chan <http://stackoverflow.com/users/813471/chan>* >> > > > > -- > Gayan Gunawardana > Software Engineer; WSO2 Inc.; http://wso2.com/ > Email: [email protected] > Mobile: +94 (71) 8020933 > Blog: http://gayanj2ee.blogspot.com/ > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulitha.me <http://dulitha.me>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>* *~Github @dulichan <https://github.com/dulichan>* *~SO @chan <http://stackoverflow.com/users/813471/chan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
