NERD TOPIC: Directory Services Help

[Miles]

Anybody familiar with directory services like LDAP or Active Directory? I need to pick someone's brain on this topic.

[CameronBornAndBred]

Anybody familiar with directory services like LDAP or Active Directory?

yes. AD anyways.

[DukeUsul]

Anybody familiar with directory services like LDAP or Active Directory?

yes. AD anyways.

I've done some development building interfaces to directories using LDAP. Particularly, I've built some Java classes that we used to pull information from Oracle Internet Directory using standard LDAP calls. I've also written a tiny bit of PL/SQL to pull LDAP data into a procedure in an Oracle DB.

By no means an expert, but I've gotten my hands dirty.

[Jesus_hurley]

AD and OpenLDAP here

[Miles]

Ugh, I don't even know where to start.

[CameronBornAndBred]

Ugh, I don't even know where to start.

Welll...then we don't either.

[Miles]

For starters: when should my product support LDAP? I'll think of more later and try to come back with well-formed questions.

[DukeUsul]

For starters: when should my product support LDAP? I'll think of more later and try to come back with well-formed questions.

If it's going to be used in any self-respecting enterprise environment it's a must.

[Miles]

For starters: when should my product support LDAP? I'll think of more later and try to come back with well-formed questions.

If it's going to be used in any self-respecting enterprise environment it's a must.

As far as I can tell, the only applied use we'd get out of supporting LDAP is user authentication, which I recognize is huge. But how would a customer go about integrating our product, assuming it supported LDAP? Here's some background.

Our product guides users through a digital workflow associated with color proofing. Customers can design an automated workflow that assigns tasks to other users based upon the file status, and a few other key metadata fields. In a non-LDAP integrated installation, customers create User Accounts and then assign them roles and responsibilities.

Now here's my question. So I "point" my user database at the LDAP server and suck in a bunch of user accounts? This gets me usernames, passwords, and their metadata (address, phone number, email, etc.) right? What about assigning roles to those users? Are they now slurped into my database (MySQL) where they have unique ids? What does it look like on our side?

Is that open-ended enough? Thanks for taking your time to answer and feel free to school me or point me in a direction where I can learn some stuffs.

[DukeUsul]

For starters: when should my product support LDAP? I'll think of more later and try to come back with well-formed questions.

If it's going to be used in any self-respecting enterprise environment it's a must.

As far as I can tell, the only applied use we'd get out of supporting LDAP is user authentication, which I recognize is huge. But how would a customer go about integrating our product, assuming it supported LDAP? Here's some background.

Our product guides users through a digital workflow associated with color proofing. Customers can design an automated workflow that assigns tasks to other users based upon the file status, and a few other key metadata fields. In a non-LDAP integrated installation, customers create User Accounts and then assign them roles and responsibilities.

Now here's my question. So I "point" my user database at the LDAP server and suck in a bunch of user accounts? This gets me usernames, passwords, and their metadata (address, phone number, email, etc.) right? What about assigning roles to those users? Are they now slurped into my database (MySQL) where they have unique ids? What does it look like on our side?

Is that open-ended enough? Thanks for taking your time to answer and feel free to school me or point me in a direction where I can learn some stuffs.

I wouldn't slurp all the user info in. I would turn the authentication routine into a hook into the LDAP system. Pass off the actual authentication to the directory. All good directories only store a hashed/encrypted password, so if you sucked the password in, you'd not have the key to actually verify the password against it. Just pass the authentication request off to the directory, get a success/fail message back and go from there.

I can pass you more info on how to do that if needed.

This is the #1 benefit of leveraging the LDAP - your users passwords will be synchronized with what's in the directory, and your normal password reset/help desk process can handle users who get locked out. You can also use whatever existing process exists to create those user accounts in the first place.

I think the question of whether to store user roles in your app database or in the directory is a more fine-grained question. It's possible to create groups in the LDAP directory and put users in them using your directory tools. Then when you authenticate them, at the same time ask the LDAP to return the list of groups the user is a member of. All you need to store in the DB is the mapping of group to privilege. We do this quite a bit, since we have custom applications and COTS products that all rely on the same group membership in the LDAP to assign privileges. It's easier to just do it in the directory than to have to incorporate it into multiple systems.

You could go even further and store NO user information in your tables ... you could just use LDAP calls to get user names, phone numbers, emails, etc.

[Miles]

I wouldn't slurp all the user info in. I would turn the authentication routine into a hook into the LDAP system. Pass off the actual authentication to the directory. All good directories only store a hashed/encrypted password, so if you sucked the password in, you'd not have the key to actually verify the password against it. Just pass the authentication request off to the directory, get a success/fail message back and go from there.

I can pass you more info on how to do that if needed.

This is the #1 benefit of leveraging the LDAP - your users passwords will be synchronized with what's in the directory, and your normal password reset/help desk process can handle users who get locked out. You can also use whatever existing process exists to create those user accounts in the first place.

I think the question of whether to store user roles in your app database or in the directory is a more fine-grained question. It's possible to create groups in the LDAP directory and put users in them using your directory tools. Then when you authenticate them, at the same time ask the LDAP to return the list of groups the user is a member of. All you need to store in the DB is the mapping of group to privilege. We do this quite a bit, since we have custom applications and COTS products that all rely on the same group membership in the LDAP to assign privileges. It's easier to just do it in the directory than to have to incorporate it into multiple systems.

You could go even further and store NO user information in your tables ... you could just use LDAP calls to get user names, phone numbers, emails, etc.

Great explanation. I think I can see how this works now. We'll definitely need to extract metadata like usernames, address, phone numbers, emails etc from the directory because our product processes reports that use this metadata. The info is displayed in reports and is used to build filters to sort data.

Still a little fuzy on user roles though. Roles are a critical part of the product because they help shape the workflow. The privileges and workflow events defined by the role are unique to our product though and they differ from each customer to the next. For example "Edit Source Profile" is a very specific color management privilege, and it's a totally foreign concept to the systems that will integrate our product. So it seems that these types of roles must be defined in our application database.

If that is true, is it possible/straightforward to map user accounts from the LDAP directory to the a Role/Group in our application database? I assume this is what you refer to by "...store in the DB is the mapping of group to privilege."

Thanks for your time and advice. I owe you beer and chili.