Allow ldap auth via rest api

[issuemover631]

Issue by muff1nman
Saturday Feb 25, 2017 at 23:47 GMT
Originally opened as https://github.com/Libresonic/libresonic/issues/258

---

When I was fixing up the ldap auth a week or so back I noticed that the REST api stuff uses a different authentication mechanism which makes it so that ldap authentication does not work via the REST api and by extension android apps. We should really change the auth mechanism on the REST endpoints to use the same auth as the rest of the app. This might be work that should be done along with #69.

[issuemover631]

Comment by EugeneKay
Tuesday Feb 28, 2017 at 23:41 GMT

---

I'm confused; I am using LDAP authentication just fine?

[issuemover631]

Comment by muff1nman
Wednesday Mar 01, 2017 at 01:07 GMT

---

Via an Android app? That would be surprising.

[muff1nman]

Verified this is an issue today with the dsub app

[thallian]

For some reason the DSub Variant from F-Droid works for me with LDAP auth. None of the other apps though.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kykc]

Strangely, I can confirm @thallian statement: D-Sub from F-Droid works fine with airsonic 10.1.2 and LDAP, but D-Sub from play market doesn't

[jooola]

Dsub from fdroid is stalled at version 5.0.3. Current version is 5.4.2 on his github releases page and should be the same on the play store.

[kykc]

Yep, that's the reason. I've compiled 5.4.2 floss version from sources and it's not working. If I will have enough spare time I'll try to pinpoint exact version of D-Sub when this stopped working and peek and the diff involved, maybe I'll get some insights regarding the issue.

[hjone72]

I've narrowed the cause down to a change between v5.2.2 and v5.3 of DSub. Hope that helps...
daneren2005/Subsonic@5.2.2...5.3

[muff1nman]

cc @daneren2005

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[PoGo606]

Same problem here, can't connect with Dsub from Play Store and LDAP auth configured...

Just sent a mail to @daneren2005 about this. Hope it will be patched soon !

[hjone72]

@PoGo606 The problem can be found here: popeen/Booksonic-App#68 (comment)

I'm not sure how to fix it however I used nginx subfilter to change the response and got it working.

        sub_filter_types text/xml application/json;
        sub_filter_once off;
        sub_filter 'subsonic' 'madsonic';

[PoGo606]

Thank you @hjone72 for your answer.

Actually, I think I have a different issue here.
Local and LDAP accounts are KO with Dsub but OK when using Subsonic official app.
Looking at HTTP requests/response it seems the issue is from the API auth mecanism used by Dsub.

Here is the request made by DSUB App:
GET /airsonic/rest/ping.view?u=pogo&s=xxxxxxxxxxx&t=xxxxxxxxxxx&v=1.2.0&c=DSub HTTP/1.1

Response:
<?xml version="1.0" encoding="UTF-8"?> <subsonic-response xmlns="http://subsonic.org/restapi" status="failed" version="1.15.0"> <error code="40" message="Wrong username or password."/> </subsonic-response>

Same with official Subsonic app:
POST /airsonic/rest/ping.view?u=pogo&p=enc:xxxxxxxxxxxxxxxxxx&v=1.2.0&c=android HTTP/1.1

Response:
<?xml version="1.0" encoding="UTF-8"?> <subsonic-response xmlns="http://subsonic.org/restapi" status="ok" version="1.15.0"/>

Both App are working well with official Subsonic server.
So it seems Airsonic doesn't handle well the first auth mecanism (GET + Encrypted + Salted ?)

[hjone72]

There is GET request that the app does to find out what capabilities the server has. If the server returns 'subsonic' the app thinks the server supports (GET + Encrypted + Salted). When the server responds with 'madsonic' it uses the old method.

It was a while ago that I found these bits and pieces so I'm just working from memory here. I believe it could be fixed either at the app end or the server end. I didn't have time to figure it out so just put a dirty hack in place. :)

[dvdkon]

The challenge-response mechanism of sending md5(password + nonce) requires knowing the plain-text password on the server. However, Airsonic's LDAP auth works by getting the plain-text password from the user and trying to authenticate ("bind") to the LDAP server with it, so this challenge-response scheme can't work with it, or any reasonable external auth mechanism.

This isn't so tragic. Sending plain-text passwords over HTTPS is arguably much more secure than storing them in a database, and everyone should be using HTTPS by now, so I'd recommend deprecating this authentication mechanism. Hopefully it will make at least some clients switch to the other, ironically more modern, method.

EDIT: By the way, the MD5-based auth isn't even a passable challenge-response scheme. The main purpose of such a scheme is to make it harder to get the password by packet sniffing. You may, however, notice that there's no "challenge" phase in Subsonic's auth mechanism. Since the nonce is chosen by the client, there's nothing preventing a replay attack by simply sending both s and t as captured. This of course doesn't matter if HTTPS is used.

[loki666]

what are you suggesting to deprecate ? LDAP auth or md5(password + nonce) ?

[dvdkon]

Sorry I wasn't clear, the md5(password + nonce) one.

[jmccoy555]

@PoGo606 The problem can be found here: popeen/Popeens-DSub#68 (comment)

I'm not sure how to fix it however I used nginx subfilter to change the response and got it working.

        sub_filter_types text/xml application/json;
        sub_filter_once off;
        sub_filter 'subsonic' 'madsonic';

Does the trick, just add --with-http_sub_module \ if you build Nginx

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[frdbonif]

@PoGo606 The problem can be found here: popeen/Popeens-DSub#68 (comment)
I'm not sure how to fix it however I used nginx subfilter to change the response and got it working.

        sub_filter_types text/xml application/json;
        sub_filter_once off;
        sub_filter 'subsonic' 'madsonic';

Does the trick, just add --with-http_sub_module \ if you build Nginx

An old issue, I know. I've just got everything up and running with LDAPS authentication but can't get DSub authenticating. Can you or anyone else clarify where I put this into the Nginx configuration?

I guess that in reality this is an issue that needs looking at within the DSub code itself?