Hi, Would like to update about a change in this space than what we discussed above.
Now empty roles can be created with default carbon user store--which is apacheds embedded-ldap. This was done in order to preserve the default carbon behavior in creating roles. It was achieved by editing the embedded-ldap schema to make member attribute an optional one. Another configuration parameter was introduced to user-mgt.xml as "EmptyRolesAllowed", and it is set to 'true' when user store is embedded-ldap, and if some one is connecting to an external ldap, this parameter's value is by default set to 'false' since usually empty groups are not allowed in LDAP. Related jira: CARBON-9220 <https://wso2.org/jira/browse/CARBON-9220> Thanks, Hasini. On Thu, Mar 10, 2011 at 10:10 AM, Hasini Gunasinghe <[email protected]> wrote: > 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
