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
