[jira] [Comment Edited] (SYNCOPE-354) LDAP Membership propagation does not process DELETE operations

["Francesco Chicchiriccò (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SYNCOPE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631633#comment-13631633 ] 

Francesco Chicchiriccò edited comment on SYNCOPE-354 at 4/15/13 10:45 AM:
--------------------------------------------------------------------------

Here it follows the tests I've been running about this, in the standalone distribution / embedded mode.

A
A.1 create role 'ldapRole' with resource LDAP assigned => ldapRole found on LDAP
A.2 create user 'ldapUser' with role 'ldapRole' and no resource assigned => ldapUser found on LDAP, with ldapRole assigned
A.3 unassign 'ldapRole' from 'ldapUser' in Syncope => ldapUser not assigned anymore to ldapRole in Syncope, ldapUser removed from LDAP (correct because ldapUser was present in LDAP only because of ldapRole's assigned resource)

B
B.1 same as A.1
B.2 same as A.2
B.3 drop role 'ldapRole' from Syncope => ldapRole removed from either Syncope and LDAP, ldapUser still on LDAP (this is to be fixed, ldapUser is present in LDAP only because of ldapRole's assigned resource - see SYNCOPE-357)

In order to reproduce what you report in the description, I need some more details, possibly in the form of the two examples above, to make clear when operations are made in Syncope and when instead are made into the external LDAP resource (via ldapmodify or similar).

About the subject, i.e. LDAPMembershipPropagationActions not processing DELETE operations, this is not completely correct: it should be "LDAPMembershipPropagationActions not processing DELETE operations for users, when role mapping is not configured", as pulled in by the whole if statement:

        if (ResourceOperation.DELETE != task.getPropagationOperation()
                && AttributableType.USER == task.getSubjectType() && task.getResource().getRmapping() != null)

The purpose of this class is to propagate memberships (i.e. user assignments to roles) from Syncope to LDAP: for doing so, a special "ldapGroups" attribute is added to the set of attributes sent to the external LDAP resource. Such special attribute is handled by the ConnId LDAP connector and interpreted as a set of LDAP role DNs to be assigned to the LDAP user entry.
Here is why this code makes sense only for CREATE or UPDATE, only for users, and only when the same resource has both mapping for users and roles.

P.S. As said for SYNCOPE-355, user ML is better place for checking unexpected behaviors than JIRA: an issue can eventually be opened, if unexpected behavior is confirmed to be a bug
                
      was (Author: ilgrosso):
    Here it follows the tests I've been running about this, in the standalone distribution / embedded mode.

A
A.1 create role 'ldapRole' with resource LDAP assigned => ldapRole found on LDAP
A.2 create user 'ldapUser' with role 'ldapRole' and no resource assigned => ldapUser found on LDAP, with ldapRole assigned
A.3 unassign 'ldapRole' from 'ldapUser' in Syncope => ldapUser not assigned anymore to ldapRole in Syncope, ldapUser removed from LDAP (correct because ldapUser was present in LDAP only because of ldapRole's assigned resource)

B
B.1 same as A.1
B.2 same as A.2
B.3 drop role 'ldapRole' from Syncope => ldapRole removed from either Syncope and LDAP, ldapUser still on LDAP (this is to be fixed, ldapUser is present in LDAP only because of ldapRole's assigned resource)

In order to reproduce what you report in the description, I need some more details, possibly in the form of the two examples above, to make clear when operations are made in Syncope and when instead are made into the external LDAP resource (via ldapmodify or similar).

About the subject, i.e. LDAPMembershipPropagationActions not processing DELETE operations, this is not completely correct: it should be "LDAPMembershipPropagationActions not processing DELETE operations for users, when role mapping is not configured", as pulled in by the whole if statement:

        if (ResourceOperation.DELETE != task.getPropagationOperation()
                && AttributableType.USER == task.getSubjectType() && task.getResource().getRmapping() != null)

The purpose of this class is to propagate memberships (i.e. user assignments to roles) from Syncope to LDAP: for doing so, a special "ldapGroups" attribute is added to the set of attributes sent to the external LDAP resource. Such special attribute is handled by the ConnId LDAP connector and interpreted as a set of LDAP role DNs to be assigned to the LDAP user entry.
Here is why this code makes sense only for CREATE or UPDATE, only for users, and only when the same resource has both mapping for users and roles.

P.S. As said for SYNCOPE-355, user ML is better place for checking unexpected behaviors than JIRA: an issue can eventually be opened, if unexpected behavior is confirmed to be a bug
                  
> LDAP Membership propagation does not process DELETE operations
> --------------------------------------------------------------
>
>                 Key: SYNCOPE-354
>                 URL: https://issues.apache.org/jira/browse/SYNCOPE-354
>             Project: Syncope
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.0
>         Environment: n/a
>            Reporter: James Flemer
>            Assignee: Francesco Chicchiriccò
>              Labels: delete, ldap, propagation, role
>             Fix For: 1.1.1, 1.2.0
>
>
> Configure a LDAP connector and resource, use the LDAPMembershipPropagationActions propagator class, add a LDAP role to a user, then try to remove that role.  The role is removed in Syncope but not LDAP; the next sync will add it back in Syncope.
> In LDAPMembershipPropagationActions, line 75 (Syncope 1.1.0), there is a conditional on:
>     ResourceOperation.DELETE != task.getPropagationOperation
> So LDAPMembershipPropagationActions refuses to process any delete operations.
> Should the operation be DELETE here (vs UPDATE)?  If so, LDAPMembershipPropagationActions needs to deal with DELETE appropriately.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira