httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [users@httpd] Sspi login prompts - enable more than one
Date Tue, 23 Sep 2008 01:58:23 GMT
Gallardo, Lisa wrote:
[...]
a) Potentially could be up to everyone who has an account - up to 1000 + 
- although not all at once - maybe 10-50 at a time
b) This site is available to staff both inside and outside the network, 
so they could access at the library, at their home, etc. Just need 
internet connection.
c) The information is primarily documents and news used internally, no 
finance or confidential info. It is for staff only and may in the future 
store this type of info.
d) Users may use Firefox, IE, etc. and their own computers

Well, that pretty much eliminates NTLM ( = Windows Integrated 
Authentication) for the people outside.

In any case, this is not going to be a simple setup where someone can 
just tell you to change this or that setting in sspi to make it work.

Let me give you a few pointers :

Normally in Apache, it should be possible to configure authentication so 
that one method is tried first, and if it does not succeed, another is 
tried afterward.
The question is that this depends a bit on the modules used (if they are 
flexible and clean or not in that respect).
It should be possible to configure sspi to try first, and if it does not 
obtain a user-id (in this case, if the user is outside), let another 
method take over.
At the sspi level, that would be done (probably) by the following 
parameter :
SSPIAuthoritative  - set to 'off' to allow access control to be passed
       along to lower modules if the UserID is not known to
       this module

(but don't do this until you actually have another authentication module 
behind sspi)

Then you would also need to configure another Apache authentication 
module, which would take over when sspi gives up.
How to configure this, I am not quite sure.

2) One issue is *what* this second module should be.
Your users can be out on the Internet, with their own computers, and 
their own browser. That's about the worst-case scenario in terms of 
authentication.

Browsers, in general and by themselves, support 2 types of 
authentication : Basic and Digest.
- Basic authentication is not secure at all, because the user-id and 
password (entered by the user in a login dialog), are then sent by the 
browser to the server in clear (actually encoded Base64, but that is not 
an encryption, it's just an encoding). That means that anyone that can 
capture a packet can get the user's user-id and password.
This is particularly bad in your case, because users being humans, they 
will want to use the same user-id and password as in the internal 
network, so a hacker that gets the "outside" user-id and pw also gets 
the one for the inside Domain.
- Digest is a bit more secure, because the user-id and password do not 
circulate directly on the network. What circulates is a hash composed on 
the base of user-id, password and other things.  If someone captures the 
conversation, they would be able to use this hash to gain access to your 
server, but at least they can not use the user-id and password for 
something else.
- IE and Firefox (with an add-on) also support NTLM, but this will not 
work outside with IE, because IE will not do that if the workstation is 
not already logged-in in the Domain.
- another way, is to run all outside accesses over HTTPS, and have e.g. 
a login page and a method behind that sets a cookie, and re-uses that 
cookie at each access to provide the "single-sign-on".
That is supported by all browsers, is very secure and may be in the end 
be the best solution, but I am not competent with HTTPS and you would 
need someone else to help you.

So unless you want the HTTPS solution, the one that might be possible 
would be something like :
- sspi tries first
- if it works, ok (that basically means the user is inside)
- if it does not work, fall back to LDAP on the server side,
     with a browser exchange using Digest authentication.
This might be possible using mod_auth_digest, with the
"AuthDigestProvider" directive to indicate an LDAP provider such as 
mod_authnz_ldap.
But I am not quite sure how to do that, because the Apache documentation 
does not seem to make a direct link between these two (as it does 
between mod_auth_basic and mod_authnz_ldap).
And I am not quite sure if sspi really works well with another 
authentication module behind it.

See, what you want to avoid is that, when sspi first sends a 401 header 
(authorization required, type = NTLM), the browser would automatically 
fall back and do a Basic authentication.  Because that is what is 
happening now, and it would send the user-id and password in clear over 
the Internet.  You do not want that to happen in your case.

There may be other solutions, such as this kind :
a first filter module which determines (on the base of the remote IP) if 
the user is inside or outside, and depending on the case re-directs the 
browser to the appropriate section of the website (or Virtual Host), set 
up with the appropriate kind of authentication (sspi or digest/ldap).
I can think of a way to do this using mod_perl, but it represents some work.
Maybe you could have a look at mod_rewrite for this also.

Or maybe this :
would it be acceptable for your users to use a different hostname 
depending on wether they are inside or outside ?
If yes, then it would be a bit easier : you could set up two Virtual 
Hosts (one for inside and one for outside) and have a different 
authentication method on each (sspi inside, another outside).
That would at least avoid the issue of having two authentication methods 
working together.
Your Virtual Hosts could share the same document space (DocumentRoot 
directory).


Anyone else with a better idea ?


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message