Using LDAP Directory Server to hold personnel information


Performance and scalability: Using LDAP Directory Server to hold personnel information

  1. Hello,

    This is a question about best practices in using directory services. Here's the problem:

    We are a very large distribution company, with lots of retail outlets state wide, and a work force consisting of over 1000 employees (at least). We are currently in the process of building a new HRMS. Part of the system will be Web based, and will be using J2EE technology. We are using WebLogic App server and Oracle DB at the back end.

    The employees may connect to the system locally through LAN, or they might be located in geographically separate areas, connecting to the system via our Web Site using modem. New employee information maybe added by managers from local or remote points. Similarly, employees will be able to view and/or update their own information locally or remotely.

    We also need a single point of entry and authentication/authorization for all our Web Apps. This includes applications other than HRMS (like inventory control etc). According to current plans, Oracle DB will be used for storing all employee information. But this information must be available to non-HR applications too. One suggested solution to this problem is to have a separate schema holding only authentication information, while employee details are only stored in the HR database.

    Now, we already have an LDAP directory server (NDS), which stores personal information like Name, phone, fax, email, division, userid and password. Because of duplication of data and the single sign-on requirement, I was looking into the possibility of using NDS to store and manage HR related employee information. Question is, how much of the employee's information could be stored in a directory. I could:

    1. Potentially store all of the employee's information on a directory server (eg, salary, pay band, benefits etc), or

    2. Store only authentication and quick contact information in the directory while all details reside in the Oracle DB. In this case, the login Id would be acting as the primary key.

    The directory server's built in security infrastructure can be used to implement role based security (another requirement for our applications).

    One of the drawbacks of storing all the personal information in directory server (which I can think of) is update performance. Directory Servers are known to be slow in updates. But frequency of updates will be substantially lower than reads. In this case, would slow updates really matter?

    Also, since WebLogic supports creating security realms from LDAP servers, this scheme would also permit use of J2EE security model with EJBs and/or servlets and JSPs.

    Any comments on the benefits and/or trade offs of the afore mentioned approaches would be appreciated.

  2. We at the moment have/had the same problem here...
    I suggest you only use a driectory if you really have a directory structure to store... I think it makes no sense storing just logon information, simply because you would be abusing the directory server as database. And a database would definitely be faster.
    The benefit you would really get by using a directory is J2EE role based secuity... however, this normally does not suffice for larger applications because security often depends on method parametes etc. there, you'll need ACLs and other nice things which cannot be modelled by the J2EE role based security model.
    However, just don't abuse the directory server as database, because it will just be painfully slow, and if you don't have a benefit then don't do it.

    kind regards

  3. Hello,

    I have an architectural question on creating role-based security in LDAP or Oracle or WindowsNT Domain.
    May be this is out of the context of the discussing topic , but I think this is the right place to shoot this question.
    Just as we create role-based security in the LDAP , can we do it window NT domain controller ? Can we tie our JNDI context to map to NT Domain instead of LDAP of already existing NT Domain roles and use that in our Application ?
    This way application dont need to maintain another UserManagement Store. Any Suggestion will be greatly appreciated.

  4. For Windows 2000 the answer is yes. At least in theory this works because Active Directory supports LDAP through one or another way (buty I guess you knew).
    With Windows NT domains I doubt this... probably with J2EE 1.3, as it mandates integration of JAAS and there is a WIndows NT connector for JAAS.
    However, I'm not saying there is no other way, I just don't know of one. But there should definitely be proprietary connectors somewhere.