Home/ Questions/Q 6232951
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T10:12:34+00:00

I have an application built on Spring MVC that uses Hibernate for all of

  • 0

I have an application built on Spring MVC that uses Hibernate for all of it’s DB interaction needs. There is now a need to update the application to use our LDAP infrastructure to drive the user information, including basic user data, such as name and email, as well as authentication and authorization needs as well.

Since everything has been in one spot (the DB) up to now, the reports are all fairly straightforward, since Hibernate is managing retrieval of information as needed when starting with the required queries. Grabbing the users’ name, etc. is very simple, since Hibernate loads the data lazily.

With the desire to drive the user information with LDAP, Hibernate will no longer be able to populate the user information on the fly, since it won’t be managing the users’ data. How should we use LDAP to drive the user data and deal with authentication / authorization without causing to much pain when we need to grab user data like Name, etc.?

We have considered using a hybrid approach where LDAP is treated as the “source” for the data and the current system is left as-is. This would require changes to the transaction processing code to update against LDAP so that the live transaction is using up-to-date information, and also a periodic sync against LDAP to keep the application DB up-to-date for reporting purposes.

This solution seems a bit hacky, and seems to have a lot of moving parts, but I could not find much on this subject elsewhere on the web.

How should user information be handled / how should the app be structured so that all of the user information is still easily accessible and can be easily tied to the rest of the system for reporting purposes? Is there a way to integrate Spring LDAP and Hibernate so that layers above the data layer don’t have to know? Or is pulling the info from LDAP into the existing database the easiest way to go?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If you can not drop the user table at all, because it is used from other entities, then my suggestion is to separete the security stuff from the business stuff.

    This mean remove the only for security needed information from the user table (login, password, …), so that only the stuff remains that is needed to implement the buiness cases.

    Then rewrite the security stuff so that is is based on the LDAP. I guess you find a way to get the user data base object for an given prinipal.

    Only one thing will remain, how to create new user database entities if a new person get a new login. You have 3 choices, what is the best one strongly depends on your application:

    • Create the database entity if the users first login
    • Create the database entity if you first need it
    • Create the database entity when it is created in the LDAO (or some minites later) for example with an cron job, or some Spring Scheduling service.
    • 0