Gluu LDAP sync with third party application with SSO integration

By: Philip Feliprada user 31 Jan 2018 at 5:29 a.m. CST

7 Responses
Philip Feliprada gravatar
Hi again, Recently I posted about a Gluu LDAP sync issue with a third party application which is Apache Syncope(https://support.gluu.org/identity-management/4968/gluu-ldap-sync-with-third-party-application/). I was able to fix this problem by performing clean re installation of Gluu. Now I am trying the SSO integration and currently following this tutorial(https://gluu.org/docs/ce/integration/spa/oauth-js-implicit/). I was able to perform SSO and everything works fine. But the problem in my last ticket somewhat reoccured. My problem now is that I cant delete users that already performed their log in in my sample sites with SSO implementation. Basically I am deleting the users in Apache Syncope and the said user will be deleted as well in Gluu since it is already "SYNC". To go in deeper to my problem I have two scenarios: *First Scenario Actions taken are: 1.)In my client settings I set the Pre-Authorization field to true and Persist Client Authorizations field to false. (Assume other settings are set correctly) 2.)Created a user in Syncope. Created user appears in Gluu. 3.)Logged in created user in sample site with SSO integration. 4.)Deleted the user in Syncope. The said user is deleted in Gluu. *Second Scenario Actions taken are: 1.)In my client settings I set the Pre-Authorization field to false and Persist Client Authorizations field to true. (Assume other settings are set correctly) 2.)Created a user in Syncope. Created user appears in Gluu. 3.)Logged in created user in sample site with SSO integration. 4.)Deleted the user in Syncope. The said user is NOT deleted in Gluu. First Scenario provided desired results but I want to persist my user upon their first log in in my sample site that is why in the second scenario I set the Persist Client Authorization field to true and this happens. Can you give me some information as to why this happens? Does Gluu perform some kind of protection to those users that gets "persisted" upon their log in which restricts Apache Syncope from deleting the said user? Hoping for your kind response Regards, Philip
CentOS 6.0
closed

Answers

By Aliaksandr Samuseu staff 31 Jan 2018 at 5:40 a.m. CST

Copy
Aliaksandr Samuseu gravatar
Hi, Philip. >My problem now is that I cant delete users that already performed their log in in my sample sites with SSO implementation. How exactly do you perform this deletion? When user entry is used to log in once, certain subentries are created beneath it. Thus simply removing the entry itself is no more possible, first all its subentries must be removed, otherwise directory server will return an error.

By Philip Feliprada user 31 Jan 2018 at 7:44 p.m. CST

Copy
Philip Feliprada gravatar
Hi Aliaksandr, I am using the "Sync" function that Syncope has provided. Once "SYNC" i can perform actions which will also reflect in Gluu like for example if I delete a user in Syncope that user will be deleted in Gluu as well. I see that is why I am not able to delete the user because of the created subentry. May I know where and how can I remove these subentries? Is there a way not to automatically create certain subentries once the user entry is used to log in once? Thanks!

By Aliaksandr Samuseu staff 01 Feb 2018 at 9:40 a.m. CST

Copy
Aliaksandr Samuseu gravatar
>I am using the "Sync" function that Syncope has provided. Once "SYNC" i can perform actions which will also reflect in Gluu like for example if I delete a user in Syncope that user will be deleted in Gluu as well. I'm not quite sure how exactly you configure it. Does your Syncope instance have direct access to Gluu's LDAP server? Or you pull entries from Syncope with Cache Refresh only? >May I know where and how can I remove these subentries? Is there a way not to automatically create certain subentries once the user entry is used to log in once? If your Syncope instance tries to remove entries in Gluu by directly connecting to Gluu's LDAP server, then you'll need to seek assistance at Syncope's resources. It's something that Syncope must be able to somehow handle (may be there is a settings for that feature?) It's up to LDAP client to handle this, directory server will simply refuse to remove any entry which has subentries. Please also note that we can't provide assistance with 3rd party packages to our community (free) users, in most cases.

By William Lowe user 01 Feb 2018 at 11:15 a.m. CST

Copy
William Lowe gravatar
Philip, Can't you use SCIM to handle this stuff? It would be better than doing a direct LDAP connection. Thanks, Will

By Philip Feliprada user 01 Feb 2018 at 7:46 p.m. CST

Copy
Philip Feliprada gravatar
Hi Aliaksandr and Will, I have direct access to Gluu's LDAP server which I can perform pulling and pushing of users. I am also not sure if there are settings in Syncope that I can further configure to be able to handle this scenario but will try to communicate with them about this issue. Thank you for making things a lot clearer and also for helping me even though my ticket is 3rd party package related. Will keep this line in mind "It's up to LDAP client to handle this, directory server will simply refuse to remove any entry which has subentries." Regards

By Aliaksandr Samuseu staff 02 Feb 2018 at 9:33 a.m. CST

Copy
Aliaksandr Samuseu gravatar
Just for your information. [Subtree Delete Control](http://ldapwiki.com/wiki/Subtree%20Delete%20Control) is control triggering an extended delete operation supported by most modern LDAP servers. It allows deletion of the whole subtree of entries. You can check whether it's supported in OpenLDAP/OpenDJ with search like this: ``` # /opt/opendj/bin/ldapsearch -h 127.0.0.1 -p 1636 -Z -X -T -s base -D 'cn=directory manager' -j /tmp/.pw --baseDn '' '(&)' supportedControl | grep -i 1.2.840.113556.1.4.805 ``` LDAP servers of modern Gluu package I have at my disposal support it out-of-the-box. It's a client's responsibility to either remove all sub-entries one by one, or request an extended operation of this sort.

By Philip Feliprada user 04 Feb 2018 at 6:04 p.m. CST

Copy
Philip Feliprada gravatar
Information provided really helps. In the meantime I will be waiting for Syncope's response regarding this issue. Thank you so much!

Post an answer