Best Practices for Multiple Source Backend Servers

By: David Tessmann user 12 Apr 2017 at 4:08 p.m. CDT

4 Responses
David Tessmann gravatar
In our environment, we have 1 LDAP server and 3 AD domains. The LDAP server acts as the main or top level database that pulls information from HR or Student Records (we are a university), or both, depending on the account. From there we have a process that creates and populates the AD accounts as needed, based on the account in LDAP. We have another process to change passwords and sync them to all the db's as well. Not all attributes are in all databases. For example, birth date or employee status attributes are kept in the LDAP database only. Conversely, the AD domains are the only place to get group memberships. Not all attribute names match up either. For example, the key attribute in LDAP is 'uid' while it is known in the AD domains as 'employeeID." For SSO, we currently mostly use Shibboleth, which is tied into the LDAP server. The problem with that is that some apps need data from AD, such as group membership, so then we need to use ADFS. We would like to use Gluu to be the one-stop SSO by incorporating our LDAP server as well as our AD servers on the back end. There are a few issues, though, that I don't know how to overcome. Gluu does allow for the setup of multiple back end servers, but I don't see anywhere to setup Cache Refresh to map source to destination attributes for more than one server nor how to setup a different key attribute for each database (even though the value of the attribute would be the same is all databases, the names are different, as explained previously for uid/employeeID). Also, how does Gluu reconcile different values from different databases? For example, if an account is database A has a 'mail' attribute value of "myemail@gluu.com" but the same account in database B has a its mail value set to, "justemail@gluu.com", how does Gluu decide which to use? Or does it error out and not sync any values? Or does it make it a multi-valued attribute in the Gluu LDAP database and syncs both? Any information you can give me is appreciated.
Rhel72
closed

Answers

By Michael Schwartz Account Admin 12 Apr 2017 at 4:17 p.m. CDT

Copy
Michael Schwartz gravatar
There is no way to use different keys for each server. The key attribute should uniquely identify a person across all databases. If you don't have such an attribute, it's a problem--you have no way to correlate the users. In such a case, how would you detect if a person existed in both backend servers? If a person is found in two backend LDAP servers, the entries are joined via a "union" operation. There is no need to specify the source of an attribute. If you request an attribute that an LDAP server does not have, it will simply not return that attribute. So just list all the attributes you want for both servers. If you need to try again, you can delete the files in the snapshots folder, and this will force a refresh of the data. You can experiment a little. Another approach might be to specify one of your sources for identity, and then use a cache refresh script to pull data from the other source.

By David Tessmann user 12 Apr 2017 at 4:38 p.m. CDT

Copy
David Tessmann gravatar
We do have key attributes on all the servers. It is just that they go by different names. In the LDAP server it is 'uid.' In AD, it is 'employeeID." The values are exactly the same in both data bases. For example, Bob Smith has accounts in both LDAP and AD. In LDAP his uid is BS0250. In AD, it is his employeeID that is BS0250. The values are the same and identify these accounts as Bob's. I'm not a db admin so please feel free to correct me if I'm wrong, but I'm pretty sure the attribute names don't matter in relating databases. The names can be mapped to each other as long as the values match. Indeed, Gluu has this on the Cache Refresh main tab under "Source attribute to destination attribute mapping," but for only one back end database. If you are implying that to utilize two back end databases in Gluu, both data bases must be EXACTLY the same--with the same attribute names used in both--then could you please give me a use case where this would be useful because I can't think of any, except where one db is just a back-up of the other.

By Michael Schwartz Account Admin 12 Apr 2017 at 4:45 p.m. CDT

Copy
Michael Schwartz gravatar
The Cache Refresh strategy is lightweight meta-directory strategy. You can license Radiant Logic for a more complex synchronization platform that can easily handle your requirements. You are the first organization in eight years to ask for this feature. Many organizations join the data based on the `mail` or `uid` attribute. One option is to write a quick script to add this corresponding attribute to one of your datasources. Export the ldif, read it in, and write a new ldif with the mod. Python has a great module for reading ldif (`ldif.py`). If you want to put up a bounty for development of this feature, or submit a pull request on Github, we'd consider supporting such a feature.

By David Tessmann user 14 Apr 2017 at 11:15 a.m. CDT

Copy
David Tessmann gravatar
Thanks again.

Post an answer