By: FP BB user 30 Jun 2020 at 12:02 p.m. CDT

8 Responses
FP BB gravatar
Hello, I've recently deployed Gluu in our environment and am able to get LDAP (Active Directory) Cache Refresh working fine for user identity pulls. I was informed that if I wanted to "push" any user create/update operations on a local Gluu user and back into Active Directory, that I would need to leverage SCIM. After searching, i'm able to find only high level documenation on SCIMl; however wanted to know if anyone knew if there was a more detailed guide on how to successfully leverage SCIM in Gluu, to run CRUD ops back into AD at all? Thanks in advance and regards, Ben

By Michael Schwartz staff 30 Jun 2020 at 12:07 p.m. CDT

Michael Schwartz gravatar
Well, it depends how the information gets into the Gluu Server. There are a few different interception scripts that might enable you to push information back to AD. But first you need to say exactly where this write to the Gluu database is originating.

By FP BB user 30 Jun 2020 at 12:24 p.m. CDT

FP BB gravatar
@Michael.Schwartz - Thanks for the quick reply. In regards to where this write to Gluu DB is originating, it's currently configured to run a Cache Refresh against Active Directory. So flow is; Active Directory --> Gluu Cache Refresh --> Gluu DB. Since the federated user data is writing into Gluu DB, does that help answer your question at all? Thanks

By Michael Schwartz staff 30 Jun 2020 at 1:11 p.m. CDT

Michael Schwartz gravatar
No... because if AD is the source of the info... why do you need to write back to AD? And why not use the Cache Refresh interception script if it's tied to that event?

By FP BB user 30 Jun 2020 at 2:34 p.m. CDT

FP BB gravatar
@Michael.Schwartz - Understood and the intent was to try and leverage Gluu as an all-in-one IAM platform. Use case is to essentially allow access admins to log into and leverage only Gluu, when creating/updating/de-provisioning users into AD as well as other connected applications, etc. Otherwise, was a little confused per the indication on this page however; https://www.gluu.org/features/identity-management/, because it seems like you can push/pull from Gluu server into AD. But if that's not the case and I misunderstood, then makes more sense now and thanks again for your speedy response. Thanks

By Aliaksandr Samuseu staff 30 Jun 2020 at 5:18 p.m. CDT

Aliaksandr Samuseu gravatar
Gluu Server offers custom scripts of type "Update user" which should be triggered when user entry is changed in Gluu Server. So it should be possible to write a script that uses LDAP interface of AD to push the changes you do to users in Gluu Server there each time (not sure if it's called on user's removal, worth testing). Combined with Cache Refresh (with addition of another custom scripts that runs during each CR batch) you can also import changes done at AD into Gluu Server. That's just from the top of my head, I'm not aware if somebody actually tried such approach in production. Otherwise, normally it's only one way transfer - from some existing internal LDAP server into Gluu Server. I know that users who needed more advanced management capabilities were writing their own apps which handled it, using SCIM REST API to access Gluu Server's user data.

By FP BB user 01 Jul 2020 at 7:24 a.m. CDT

FP BB gravatar
@Aliaksandr.Samuseu - Thanks for your response. Are there any out-of-the-box type configs/features I can leverage then, without having to write additional scripts? Or perhaps documenation somewhere that depicts how this push/update user process is done back to AD?

By Aliaksandr Samuseu staff 01 Jul 2020 at 5:23 p.m. CDT

Aliaksandr Samuseu gravatar
No, we don't offer a ready-to-use feature like that. Normally, user data is imported into Gluu Server from external sources, not the opposite. Basically, Gluu Server just aggregates and caches this data internally, to be able to provide seamless SSO experience. To achieve what you want you would need to do some scripting, and still the final solution may be susceptible to data loss and data going out of sync, as the scripts are usually just run once, being hooked to specific event. If anything fails and script either exits or throws exception, whatever changes it failed to push to your AD server are lost (unless you somehow safeguard against it). That turns into architecture discussion, instead of being a specific question about officially supported features at that point, which I think we don't normally engage in under Community Support. May be @Michael.Schwartz still has something to add, or suggest how to handle this ticket.

By FP BB user 03 Jul 2020 at 6:44 a.m. CDT

FP BB gravatar
@Aliaksandr.Samuseu - Thanks for your response and information. I'll look into the possibility leveraging some scripts to meet our use case. Thanks again for your help and if you ever happen to locate any documentation regarding this, please do let me know.