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

Reply via email to