Hi, Thank you for the reply.
On Thu, Mar 10, 2011 at 12:28 AM, Amila Jayasekara <[email protected]> wrote: > Hi Hasini, > > Please find some comments inline. > > Thanks > AmilaJ > > On Wed, Mar 9, 2011 at 2:40 AM, Hasini Gunasinghe <[email protected]> wrote: > > Hi, > > This is implemented in user core now and I would like to mention some of > the > > implementation level decisions made while doing the $subject, which are > > different from JDBCUserStoreManager. > > If you see any flaws or better alternatives, please let me know. > > 1. 'Everyone role' and 'registry anonymous role' are carbon server > specific. > > Hence they are not written to LDAP user store. > > They are handled by hybrid role manager as it has been done with read > only > > LDAP user store. > > 2. In LDAP groups, there's a requirement that at least one user should be > a > > member. > Therefore; > When creating a role, we need to include at least one user to that > role. Otherwise an error is set to be shown through management console. > Also, when deleting a user, if that user has been the only member > of > any of the existing role, user is not allowed to be removed. (As an > alternative, may be we can remove the role also when its last user entry > is > removed). > > Conceptually this doesn't seems to be the correct thing to do. Cos we > should be able to handle roles and users independently. It might > confuse the user if we delete the role when deleting last member from > it. > Yes, I too think so. According to the schema of "groupOfNames", the "member" attribute is a > must. This is the reason why you cannot have groups without members. > Is it possible to make "member" attribute optional in the schema? > Since this change is only for embedded LDAP i guess it is ok to change > the schema. But lets get others feedback also. > Actually this is not only for embedded-ldap. This will be the implementation used with any external LDAP server as well, for user-group management in LDAP. Therefore making it coupled with the manually changed schema would not be a scalable option as I think. What if we add the admin entry by default when creating a role at code level (and we allow the user to remove admin entry from a role only if where is one other user entry in that role.) Since it is the admin who assign other users to groups, would there be a security concern that admin user is in every role at the creation of the role? Would highly appreciate the feedback on whether it is a suitable approach. > > > > I am wondering whether above would be confusing to user since it is > > different from previous behavior. > Then I would like to clarify following things too regarding this: > i. There are some user-level functionalites which include several LDAP > operations. And currently these are not atomic. Do we need to make them > atomic? > > I am +1 for making these transactions atomic as it resolves lot of > consistency issues. But i am not sure about the effort. > Yes, I have not yet figured out how to make several LDAP operations atomic. Actually, the aforementioned reason is the one which would cause an error in the middle of several operations. So if we can avoid it, then we can make sure at the code level that errors do not occur unless it is a connectivity problem to LDAP server. > > > (LDAP itself does not support transaction concept. But I read about a > > spring API which allows to make LDAP operations atomic[1].) > Currently "WriteLDAPGroups" property is set to false by default in > user-mgt.xml. > > Hope ReadLDAPGroups=false and WriteLDAPGroups=true is an invalid state. > Yes, this is been checked at the initialization of ApacheDSUserStoreManager object.. Thanks, Hasini. > > > Before configuring it to true by default, I would really appreciate any > > comments, feedback on the above > > [1] > http://static.springsource.org/spring-ldap/docs/1.3.x/reference/html/transactions > . > > Thanks, > > Hasini. >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
