Skip to content

No Actual Authentication? #1

Wardrop opened this Issue Mar 16, 2012 · 10 comments

5 participants

Wardrop commented Mar 16, 2012

By the looks of it, all this code is doing is getting the username out of the NTLM request and verifying it's existance in an LDAP directory. There is no actual authentication - anyone can spoof a username over ldap, in fact any browser that prompts for a username will allow a user to "authenticate" as anyone they want.

Am I missing something?


Authorization is still very useful.

amw commented Apr 26, 2012

Confirming the issue. No authentication is performed. All this gem does is confirming that the user (who the client claims to be) exists in AD.

@Wardrop Were you able to find some other gem to perform single sign on with active directory users?

@steakknife This gem doesn't provide any kind of authorization. Neither in theory nor in practice. I think you got this term mixed up.

Wardrop commented Apr 26, 2012

@amw No, I didn't find any other gem that performs actual authentication. I decided to go down the path of letting Apache handle NTLM authentication before deciding to post-pone implementing single sign-on for the project I was working on.

elia commented May 8, 2012

Just for information I got a decent setup in which the whole authentication is handled by IIS.
Adapting from these instructions I got IIS to act as a reverse proxy for Rails server (thin, webrick, whatever…) on a *nix machine (a Mac with Pow! in development).

Here's the iirf.ini file that I used for development:

# NOTE: This file should be placed in the IIS document root for the application

# Put the following linw in windows etc/hosts file

StatusInquiry ON
RewriteLogLevel 3
RewriteLog ..\..\TEMP\iirf
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^.*$ - [L]
ProxyPass ^/(.*)$$1
ProxyPassReverse /

# Disable HTTPS
#   RewriteCond %{HTTPS} on
#   RewriteHeader X_FORWARDED_PROTO ^$ https

With this setup you can rely on the fact that the authentication is performed by IIS and you only get authenticated request containing a Type-1 ntlm message (or Type-3, I'm not completely sure about this). I also removed rack-ntlm and kept only net-ntlm and used it to extract the username this way:

require 'kconv'
require 'net/ntlm'

if /^(NTLM|Negotiate) (.+)/ =~ env["HTTP_AUTHORIZATION"]
  encoded_message = $2
  message = Net::NTLM::Message.decode64(encoded_message)
  user = Net::NTLM::decode_utf16le(message.user)

+1 awesome for followup. :cake:

elia commented May 11, 2012

@lukefx can we close this?

amw commented May 11, 2012

I don't think we should. It should stay wide open as a warning and guide to other developers. I would go as far as suggesting to modify the project's README to say that this gem is broken and that your application will be unsecured if you decide to use it in production.

elia commented May 11, 2012

@amw you right, fixing the README is the real issue.

amw commented May 11, 2012


Well, that's not what I meant, but if no one is going to commit a real fix then it's the least we can do.

@elia elia added a commit to elia/rack-ntlm that referenced this issue May 11, 2012
@elia elia Add notice about issue #1 to README b334c7d
lukefx commented May 11, 2012

ok guys, sorry for the long waited response. I'm full time on a project but I've created a branch and I'm trying to fix the authentication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.