Re: clj-ldap - Clojure LDAP client
Hi - is anyone maintaining any of these ldap libraries?
I ask because:
- neither has updates in 2 years
- the underlying umboundid library now supplies a
"bindAndRevertAuthentication" function that implements what was discussed
previously in this thread - you can bind without mutating the existing
connections (who'd have thought you'd need that? :)
- Paul's fork doesn't let you raise issues, and there are two unapplied
pull requests, which makes me hesitant to do a patch myself.
There's also https://github.com/realestate-com-au/clj-ldap-auth by Mike
Rowe, which seems a bit beta for our needs, but if the others are abandoned
we might start working with that one.
Or is there another library out there I missed? Surely there are lots of
clojure folk doing ldap authentication!
- Korny
On 20 March 2011 23:55, Paul Dorman wrote:
> Thanks for the latest changes, Saul. Your implementation is a little
> different from mine:
>
> (defn bind-connection
> "Change the identity of an existing connection."
> [connection bind-dn password]
> (let [bind-result (.bind connection (bind-request {:bind-dn bind-
> dn :password password}))]
> (if (= ResultCode/SUCCESS (.getResultCode bind-result))
> connection
> (throw (LDAPException. bind-result)
>
> This enables the application code to handle the exception
> appropriately (was the return value false because of invalid
> credentials, or because of some other reason?). It also (I hope)
> provides the capability to take a connection from the pool, change its
> identity and perform some subsequent action(s) such as changing
> attribute values.
>
> I haven't yet confirmed if what I have above will work in the way I
> describe, but I'm pretty confident that you'll want a connection
> returned by bind/bind-connection function. A naive authentication
> scheme could be implemented by the application like so:
>
> (defn can-bind?
> [attribute value password]
> (def search-result (ldap/search conn base-dn {:filter (<<
> "(~{attribute}=~{value})") :attributes [:dn]}))
> (try
> (ldap/bind-connection conn (:dn (first search-result)) password)
> true
> (catch Exception _ false)))
>
> i.e. (can-bind? "uid" "joe" "supersecretpassword")
>
> I'm a complete beginner at Clojure (and LDAP for that matter), and
> there's a number of things that I'm wondering about, such as binding
> to a server-set, where failure to bind due to the unavailability of
> one or more members causes a bind request to be sent to the next. The
> thing I'm struggling with at the moment is how to manage connection
> state as its identity is changed for each new bind. In particular, I
> want to use getConnection() to retrieve the bind connection from the
> pool so it can be reused (which isn't currently happening), before
> calling the releaseConnection() method.
>
> Sorry for not getting the above to you earlier - I've been spending a
> lot of time in the REPL trying to get this right. 1:50 on Monday
> morning now though, so I think I'll have to reluctantly step away from
> the computer.
>
> Regards,
> Paul
>
> On Mar 20, 11:34 pm, Saul Hazledine wrote:
> > On Mar 16, 9:30 am, Ray Miller wrote:
> >
> > > On 15 March 2011 08:46, Saul Hazledine wrote:
> >
> > > > On Mar 15, 1:30 am, Paul Dorman wrote:
> > > > One thought though is that it may be quicker simply do a lookup on
> the
> > > > directory server, obtain the password and then do a compare. In
> > > > OpenLDAP, posixUser uids are indexed by default. Java libraries are
> > > > available for most password encryption algorithms. This is the
> > > > approach I use - do you know of any problems with my method?
> >
> > > Certainly when I was running LDAP servers we did not allow passwords
> > > to be retrieved from the server, as they are then susceptible to an
> > > offline dictionary attack. To authenticate users, you had to send a
> > > bind request to the server.
> >
> > This is a very good point which I have added to the documentation.
> >
> > I have made the bind functionality public and released version 0.0.4
> > of clj-ldap.
> >
> > Saul
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
Kornelis Sietsma korny at my surname dot com http://korny.info
.fnord { display: none !important; }
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more opt
Re: clj-ldap - Clojure LDAP client
Thanks for the latest changes, Saul. Your implementation is a little
different from mine:
(defn bind-connection
"Change the identity of an existing connection."
[connection bind-dn password]
(let [bind-result (.bind connection (bind-request {:bind-dn bind-
dn :password password}))]
(if (= ResultCode/SUCCESS (.getResultCode bind-result))
connection
(throw (LDAPException. bind-result)
This enables the application code to handle the exception
appropriately (was the return value false because of invalid
credentials, or because of some other reason?). It also (I hope)
provides the capability to take a connection from the pool, change its
identity and perform some subsequent action(s) such as changing
attribute values.
I haven't yet confirmed if what I have above will work in the way I
describe, but I'm pretty confident that you'll want a connection
returned by bind/bind-connection function. A naive authentication
scheme could be implemented by the application like so:
(defn can-bind?
[attribute value password]
(def search-result (ldap/search conn base-dn {:filter (<<
"(~{attribute}=~{value})") :attributes [:dn]}))
(try
(ldap/bind-connection conn (:dn (first search-result)) password)
true
(catch Exception _ false)))
i.e. (can-bind? "uid" "joe" "supersecretpassword")
I'm a complete beginner at Clojure (and LDAP for that matter), and
there's a number of things that I'm wondering about, such as binding
to a server-set, where failure to bind due to the unavailability of
one or more members causes a bind request to be sent to the next. The
thing I'm struggling with at the moment is how to manage connection
state as its identity is changed for each new bind. In particular, I
want to use getConnection() to retrieve the bind connection from the
pool so it can be reused (which isn't currently happening), before
calling the releaseConnection() method.
Sorry for not getting the above to you earlier - I've been spending a
lot of time in the REPL trying to get this right. 1:50 on Monday
morning now though, so I think I'll have to reluctantly step away from
the computer.
Regards,
Paul
On Mar 20, 11:34 pm, Saul Hazledine wrote:
> On Mar 16, 9:30 am, Ray Miller wrote:
>
> > On 15 March 2011 08:46, Saul Hazledine wrote:
>
> > > On Mar 15, 1:30 am, Paul Dorman wrote:
> > > One thought though is that it may be quicker simply do a lookup on the
> > > directory server, obtain the password and then do a compare. In
> > > OpenLDAP, posixUser uids are indexed by default. Java libraries are
> > > available for most password encryption algorithms. This is the
> > > approach I use - do you know of any problems with my method?
>
> > Certainly when I was running LDAP servers we did not allow passwords
> > to be retrieved from the server, as they are then susceptible to an
> > offline dictionary attack. To authenticate users, you had to send a
> > bind request to the server.
>
> This is a very good point which I have added to the documentation.
>
> I have made the bind functionality public and released version 0.0.4
> of clj-ldap.
>
> Saul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
On Mar 16, 9:30 am, Ray Miller wrote: > On 15 March 2011 08:46, Saul Hazledine wrote: > > > On Mar 15, 1:30 am, Paul Dorman wrote: > > One thought though is that it may be quicker simply do a lookup on the > > directory server, obtain the password and then do a compare. In > > OpenLDAP, posixUser uids are indexed by default. Java libraries are > > available for most password encryption algorithms. This is the > > approach I use - do you know of any problems with my method? > > Certainly when I was running LDAP servers we did not allow passwords > to be retrieved from the server, as they are then susceptible to an > offline dictionary attack. To authenticate users, you had to send a > bind request to the server. > This is a very good point which I have added to the documentation. I have made the bind functionality public and released version 0.0.4 of clj-ldap. Saul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
On 15 March 2011 08:46, Saul Hazledine wrote: > On Mar 15, 1:30 am, Paul Dorman wrote: > One thought though is that it may be quicker simply do a lookup on the > directory server, obtain the password and then do a compare. In > OpenLDAP, posixUser uids are indexed by default. Java libraries are > available for most password encryption algorithms. This is the > approach I use - do you know of any problems with my method? Certainly when I was running LDAP servers we did not allow passwords to be retrieved from the server, as they are then susceptible to an offline dictionary attack. To authenticate users, you had to send a bind request to the server. Ray. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
On Mar 15, 11:14 am, Paul Dorman wrote: > Hi Saul, > > I'm happy to wait until Friday, but check your request queue before > you make the change yourself as I may submit one. I've made the change > on my own fork, but I've only changed the function definition from > private to public; I haven't looked into the changes required for > testing and documentation. That's totally fine. I don't mind doing tests if you don't have time. Since you have a clearer idea on how to use the changes, I recommend that you do the documentation (even if its just rough notes). > > I'd probably prefer the approach I described partly to keep the > overhead of decryption on the LDAP server rather than on my > application server. Strictly speaking from ignorance, I'd guess that > the LDAP server would perform the decryption a little faster, and with > a smaller memory footprint. Also, binding to the LDAP server means > that your application only needs to know how to negotiate a secure > connection over LDAPS, irrespective of the encryption scheme used on > the directory server, removing the requirement to build in support for > every scheme likely to be encountered in the wild (which might also > introduce legal complications). I see the advantages now. Saul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
On Mar 15, 11:16 am, Jozef Wagner wrote:
> Hi,
>
> Could you please license clj-ldap under open source license?
>
> JW
Its in the project.clj but I'll make it clearer in the README.
(defproject clj-ldap "0.0.3"
:description "Clojure ldap client"
:url "https://github.com/alienscience/clj-ldap";
:dependencies [[org.clojure/clojure "1.2.0"]
[org.clojure/clojure-contrib "1.2.0"]
[com.unboundid/unboundid-ldapsdk "2.0.0"]]
:dev-dependencies [[swank-clojure "1.2.1"]
[org.apache.directory.server/apacheds-all
"1.5.5"]
[org.slf4j/slf4j-simple "1.5.6"]
[clj-file-utils "0.2.1"]]
:license {:name "Eclipse Public License - v 1.0"
:url "http://www.eclipse.org/legal/epl-v10.html";
:distribution :repo
:comments "same as Clojure"})
Saul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
Hi Saul, I'm happy to wait until Friday, but check your request queue before you make the change yourself as I may submit one. I've made the change on my own fork, but I've only changed the function definition from private to public; I haven't looked into the changes required for testing and documentation. Like about every other geek in the world I'm time-poor and spending much of my spare time learning Clojure (*while* writing my first app). It would be a good exercise though, so, as I said, check your requests. I'd probably prefer the approach I described partly to keep the overhead of decryption on the LDAP server rather than on my application server. Strictly speaking from ignorance, I'd guess that the LDAP server would perform the decryption a little faster, and with a smaller memory footprint. Also, binding to the LDAP server means that your application only needs to know how to negotiate a secure connection over LDAPS, irrespective of the encryption scheme used on the directory server, removing the requirement to build in support for every scheme likely to be encountered in the wild (which might also introduce legal complications). On the other hand, your method requires less trips, but I'm not sure how much impact it would have if it were independent of web traffic and over a fast local connection. Paul On Mar 15, 9:46 pm, Saul Hazledine wrote: > On Mar 15, 1:30 am, Paul Dorman wrote: > > > Hi Saul, > > > I would like to implement a LDAP authentication in Clojure, based > > around clj-ldap. Do you think it is necessary for the bind-request > > function to be private? In LDAP v3 bind requests can be sent at any > > time during a connection, so I can run a small connection pool for > > authentication without the overhead of creating a new connection every > > time someone authenticates. My plan is to take the UID and password, > > search the directory for the matching DN, and then bind with that DN > > given the provided password. > > changes > > I had no idea you could do that - cool. > > One thought though is that it may be quicker simply do a lookup on the > directory server, obtain the password and then do a compare. In > OpenLDAP, posixUser uids are indexed by default. Java libraries are > available for most password encryption algorithms. This is the > approach I use - do you know of any problems with my method? > > > Any enormous flaws in this approach? More specifically, would you > > consider a public bind-request function in an upcoming release? > > I can see no flaws with your approach. I can do this on Friday if you > don't mind waiting. Otherwise, if you want to make the changes > yourself to the master branch, do a pull request and I'll gladly merge > in the new functionality. > > Saul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
Hi, Could you please license clj-ldap under open source license? JW -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
On Mar 15, 1:30 am, Paul Dorman wrote: > Hi Saul, > > I would like to implement a LDAP authentication in Clojure, based > around clj-ldap. Do you think it is necessary for the bind-request > function to be private? In LDAP v3 bind requests can be sent at any > time during a connection, so I can run a small connection pool for > authentication without the overhead of creating a new connection every > time someone authenticates. My plan is to take the UID and password, > search the directory for the matching DN, and then bind with that DN > given the provided password. > changes I had no idea you could do that - cool. One thought though is that it may be quicker simply do a lookup on the directory server, obtain the password and then do a compare. In OpenLDAP, posixUser uids are indexed by default. Java libraries are available for most password encryption algorithms. This is the approach I use - do you know of any problems with my method? > Any enormous flaws in this approach? More specifically, would you > consider a public bind-request function in an upcoming release? > I can see no flaws with your approach. I can do this on Friday if you don't mind waiting. Otherwise, if you want to make the changes yourself to the master branch, do a pull request and I'll gladly merge in the new functionality. Saul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
Hi Saul, thanks for writing this. Embarrassingly I wasn't even aware of the UnboundID LDAP SDK, so it's great to find two useful things I can use right away! I would like to implement a LDAP authentication in Clojure, based around clj-ldap. Do you think it is necessary for the bind-request function to be private? In LDAP v3 bind requests can be sent at any time during a connection, so I can run a small connection pool for authentication without the overhead of creating a new connection every time someone authenticates. My plan is to take the UID and password, search the directory for the matching DN, and then bind with that DN given the provided password. Any enormous flaws in this approach? More specifically, would you consider a public bind-request function in an upcoming release? Paul On Feb 11, 1:37 am, Saul Hazledine wrote: > On Feb 10, 8:36 am, Jozef Wagner wrote: > > > One question, If I search for some entries, you return results as a sequence > > of maps. How do I get dn of some result? It seems that your entry-as-map > > converts attributes but strips away entry dn. > > > I've solved this by adding :dn key in each entry map, > > seehttps://github.com/wagjo/dredd/blob/master/src/dredd/ldap.clj#L19 > > Many thanks for spotting this important missing attribute. Thanks also > for the link to your code. After reading your version I realised that > clj-ldap should also allow attributes to be selected for an ldap/get. > > I've fixed the problem with dn, added attribute selection to ldap/get, > improved the README slightly and released this as version 0.0.2 which > is now on clojars.org. > > Saul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clj-ldap - Clojure LDAP client
On Feb 10, 8:36 am, Jozef Wagner wrote: > One question, If I search for some entries, you return results as a sequence > of maps. How do I get dn of some result? It seems that your entry-as-map > converts attributes but strips away entry dn. > > I've solved this by adding :dn key in each entry map, > seehttps://github.com/wagjo/dredd/blob/master/src/dredd/ldap.clj#L19 > Many thanks for spotting this important missing attribute. Thanks also for the link to your code. After reading your version I realised that clj-ldap should also allow attributes to be selected for an ldap/get. I've fixed the problem with dn, added attribute selection to ldap/get, improved the README slightly and released this as version 0.0.2 which is now on clojars.org. Saul -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
