Hi, Thanks AmilaJ and DimuthuL for the feedback. As I have mentioned in the first mail, the current implementation of this has taken similar approach as option 1 above. Since these are the two options we have, I will continue to keep the existing one as it is for now. And before performing bulk updates to LDAP, will add a validation step on all update operations to preserve atomicity in a way. If we encounter any usability issues in testing or in usage, we might be able to think for an alternative.
Thanks, Hasini. On Thu, Mar 10, 2011 at 8:40 AM, Dimuthu Leelarathne <[email protected]>wrote: > Hi, > > > If IIRC our first WSAS versions (Tungsten or later) did not allow to create > empty groups. If I am given two options as follows. > > 1) Do not allow to create empty groups > 2) Assign Admin user to all groups. > > I would pick option 1. I don't think option 2 is the correct behaviour. > There must be products that use LDAP and all of them are facing the same > problem. Since the problem is common the solution should be common. We > should make a decision looking at one of them. > > Thanks, > Dimuthu > > > > On Thu, Mar 10, 2011 at 7:53 AM, Amila Jayasekara <[email protected]> wrote: > >> On Wed, Mar 9, 2011 at 5:39 PM, Hasini Gunasinghe <[email protected]> >> wrote: >> > 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. >> >> I agree. >> >> > 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? >> >> Will our permission model has any effect from this ? If not this seems >> to be an OK approach. We might need to stop showing admin for each >> 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
