My apologies if I am missing the point of your question.
inline...
> -----Original Message-----
> From: Javier Borrajo [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 23, 2000 11:12 AM
> To: [EMAIL PROTECTED]
> Subject: Re: LDAP + SQL
>
<snip for Rickard :-)>
>
>
> Thanks for the answer.
>
> This solution means replicating LDAP info in the RDBMS, if
> only the user id.
How is replicating the user id any worse than "replicating" foreign keys between tables in a relational database (other than the RDBMS can ensure referential integrity)?
This is a really common design. I seen lots of people in the Site Server world (where LDAP and an RDBMS share user data in virtually every deployment) make the "key" in their relational database an dn or path to the principal in LDAP. Something along the lines of: "ldap://myserver:port/o=MyOrg/ou=MyAppsUsers/cn=MyUsername". This seems to work moderately well, though restructuring you LDAP server comes a chore. I've also applied the same sort of pattern to a Weblogic project.
I've also seen the use of mapping tables in the database where dn/paths are mapped to keys in the database (so the two systems are less coupled). I suppose you could also do a reverse mapping by adding a key attribute to your LDAP user object that contained the user key from the database.
>
> Is this what people out there are doing? Or is it nobody is using
> LDAP with workflow apps etc ?
A ton or people are doing this (because LDAP makes authentication and authorization across systems so nice). What sort of answer were you looking for?
>
> Javier
>
>
<snip for Rickard :-)>
Erik
--
Erik Huddleston, [EMAIL PROTECTED]
Chief Architect, eCustomers.com
Microsoft Java MVP
