Skip to content

No Actual Authentication? #1

Open
Wardrop opened this Issue Mar 16, 2012 · 10 comments

5 participants

@Wardrop
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?

@steakknife

Authorization is still very useful.

@amw
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
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
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
# 
#   172.18.27.252 intranet.dev
# 

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

# 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)
end
@steakknife

+1 awesome for followup. :cake:

@elia
elia commented May 11, 2012

@lukefx can we close this?

@amw
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
elia commented May 11, 2012

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

@amw
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
Owner
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.