#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0

    LDAP for a large internet application?


    Would LDAP be the right solution for arranging authentication and permissions in a large internet application?

    - about 50.000 users
    - users are members of groups like families, schools/ school classes, clubs/ teams and other groups of people
    - users can be admins or read-only users per group
    - school admins can administer all classes below, club admins the teams below
  2. #2
  3. Did you steal it?
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    13,959
    Rep Power
    9397
    If you need to tie it into Active Directory, maybe. But if not then that system can be easily modeled with a conventional database without the hassles of domain controllers and unusual queries.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    Originally Posted by Ewout
    Would LDAP be the right solution for arranging authentication and permissions in a large internet application?

    - about 50.000 users
    - users are members of groups like families, schools/ school classes, clubs/ teams and other groups of people
    - users can be admins or read-only users per group
    - school admins can administer all classes below, club admins the teams below
    50k users is small for a "real" LDAP server.
    -jim
  6. #4
  7. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    Originally Posted by jwilleke
    50k users is small for a "real" LDAP server.
    -jim
    Which LDAP servers would you consider "real"?
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    OpenLDAP, Oracle, eDirectory, ADAM (or whatever MS calls it now), probably ok with OpenDJ, ApacheDS and many more.

    One of the things to consider is load. How many user per second will be using LDAP?
    Are they only doing binds or are there LARGE searches?

    And remember, GROUPS are BAD.

    Using Active Directory as and LDAP server for applications is not IMHO recommended.

    -jim
  10. #6
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    Originally Posted by jwilleke
    And remember, GROUPS are BAD.
    -jim
    In my case users are members of one or more groups, and per group they can be admin or view-only for that group.

    How could this be implemented in a good way in LDAP, if groups are bad?
  12. #7
  13. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    Generally, in organizations, groups are typically organized by some attribute value on the user's entry.

    When a user does a login to the application, you can read the values from the user's entry.

    Why would you want to check for group membership if the user's entry already tells you what you need to know?

    Groups are usually redundant and cause more activity than necessary.

    see: ldapwiki.willeke.com/wiki/GroupsAreBad

    -jim
  14. #8
  15. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    Thanks for this Jim!

    In our case groups can form hierarchies: an admin in group 'School A' is also admin for the groups 'Class1' and 'Class2' in this school.

    Besides our application is totally focussed on groups: a user always works on the data for all the users in his group(s).

    I'm new to LDAP, but I think using attributes would not work efficiently in this situation. Should I conclude that as using 10.000+ groups is also not good, we better not use LDAP?
  16. #9
  17. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    LDAP, using groups, will still be much faster than a DB certainly in you configuration.

    You could add an attribute to the user that represents the groups they belong to.

    Perhaps a multi-valued familyAdmin attribute and a multi-valued family attribute (for RO)

    Then you could have:
    familyAdmin: willeke

    family: willeke
    family: smith

    As I first said, without a lot more details, these considerations for your specific situation may not be applicable.

    An LDAP Compare against the family for willeke would return true only if the value of willeke exists on the family attribute.

    LDAP is Lightweight. The protocol has a one byte requestType plus the data.
    The result code is always oneByte plus data.
    A DB is a client server application which has a specific client for each specific DB and the overhead is considerably higher.

    -jim
  18. #10
  19. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    Originally Posted by jwilleke
    LDAP, using groups, will still be much faster than a DB certainly in you configuration.
    -jim
    The 50.000 users I mentioned in my first post, would result in about 20.000 groups, with users beibg member of one or more groups.

    Would LDAP, using groups, even with this amount be a good solution?
  20. #11
  21. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    Good, compared to what?

    It will be faster than a DB.
    -jim
  22. #12
  23. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jun 2011
    Posts
    6
    Rep Power
    0
    Indeed compared to putting the users and groups in a database.

    Thanks a lot for your answers Jim, we will give LDAP a try!

IMN logo majestic logo threadwatch logo seochat tools logo