Authenticate from outside the Windows domain

Jan 27, 2011 at 5:33 PM

My application has its own authentication integrated, but I'm actually trying to integrate it using the SPNEGO SSO.

I had no problems to SSO authenticate IE or Firefox clients with Tomcat in the same domain and it works well.

But I would like to know when my clients are outside the windows domain, if I can bypass the SPNEGO authentication and fall in my own integrated authentication and be able to give access to the application.

I try to do it, and what I get the prompt user and password and after I get "this request requires HTTP authentication".

Artur

Coordinator
Jan 27, 2011 at 9:48 PM

Hello,

You can read http://tomcatspnego.codeplex.com/Thread/View.aspx?ThreadId=214422.

Dominique

Jan 28, 2011 at 12:02 PM

Dominique

Thank you to your fast reply that has resolved my problem.

I had read the 214422 before but "too fast", also as I'm some new to Tomcat configuration and I hadn't understand that it contained the solution for what I want to do.

Now I can take in account a progressive solution, where people can upgrade to SSO while taking in account those that don't have updated their clients if they are in the domain or those that are outside the domain windows and follows the "old" authentication.

In synthesis I make the following configuration:

in the files:

  • copy my previous "index.jsp" to "indexSSO.jsp"

In the web.xml

  • The "url-pattern" in "security-constraint" points to the single jsp page "index.SSO.jsp"
    • <security-constraint>
              <display-name>Authenticated Users</display-name>
              <web-resource-collection>
                  <web-resource-name>Authenticated Protected Area</web-resource-name>
                      <url-pattern>/indexSSO.jsp</url-pattern>
                      <http-method>GET</http-method>
              </web-resource-collection>
              <auth-constraint>
                  <role-name>myGroup\Domain Users</role-name>
              </auth-constraint>
          </security-constraint>
  • the "welcome-file" in "welcome-file-list" point to "indexSSO.jsp"
    •     <welcome-file-list>
              <welcome-file>indexSSO.jsp</welcome-file>
          </welcome-file-list>
  • Redirect the Error 401 for my original authentication page "index.jsp"
    • <error-page>
         <error-code>401</error-code>
         <location>/index.jsp</location>
      </error-page>

In my code:

  • I'm modifying my authentication code to take in account the two authentication ways. I will work from the following:
    •  if getRemoteUser() is valid I will take in account the identifier given by tomcatSpnego authentication
    • if getRemoteUser is not valid(null) is my previous authentication to be used, and the user prompted to give its identification and password.

Thanks again

Artur

 

 

Feb 23, 2011 at 10:03 AM
Edited Feb 23, 2011 at 10:54 AM

Hello,

I have a similar question,

I'm using spnego, and no problem with computer in the domain, ...
But when a computer from the outside try to connect (or without the good configuration) I have an error page 401. Is it possible in this case to have a login message box? (like in other project like waffle, ..) To have the possibility to connect from outside?

I'm using JNA version on a windows server.

 

Feb 23, 2011 at 12:26 PM

Hi,

I change what I write in message of January 28 that is not correct.

I fall in the same problem when I'm outside of Windows domain. I try also to have only one entry point in my application to cover all cases where users inside or outside the Windows domain could be covered. But in the end I create two entry points.

My application has its own "embedded authentication and authorization rules".

I have two entry points in my application:

1 -  One that its to be used by users inside the domain, this entry point is protected by the Spnego "security rules". This entry point stores in the session context the contents of getRemoteUser(). This value is used later to check if the user has authorizations to enter in the application and if valid it unlocks the "embedded application authorisation rules". I name it: "entry point 1".

2 -  The other one is to be used by users outside the domain. This entry point uses the application "embedded authentication and authorization rules". I name it: "entry point 2".

3 -  the error code "403" is redirected to entry point 2 in web.xml.

The behaviour that I get is the following:

4 - If the user is in the Windows Domain and the security rules are accepted:

 - It must use the entry point 1. The obtained flow is the following:

   - The browser send: GET <entry point 1>

   - Tomcat replies with 401 and Authorization: Negotiate

  - The browser replies with the Kerberos/NTLM authorisation

  - Tomcat: Spnego accepts the authentication, and Tomcat replies with the the contents of "entry point 1" with valid "embedded authentication and authorization rules"

5 - If the user is in the Windows Domain and the Spnego security rules are not accepted:

   - The browser send: GET <entry point 1>

   - Tomcat replies with 401 and Authorization: Negotiate

  - The browser replies with the Kerberos/NTLM authorisation

  - Tomcat -Spnego don't accepts the authentication and a 403 is generated

       - The 403 is redirected by Tomcat to the "entry point 2"

       - Tomcat displays the contents of "entry point 2"

  - The user browser is displayed with "entry point 2" and it must authenticate itself with user and password.

6 - If the user is outside the Windows domain and tries "entry point 1"

   - The browser send: GET <entry point 1>

   - Tomcat replies with 401 and Authorization: Negotiate

   - The browser don't knows the "Authorization: Negotiate" and displays the "Must authnticate"!!!

  - Note: The user must itself browse with "entry point 2"

 

I try to redirect the "error 401" to my "entry point 2" in web.xml and couldn't get nothing. In fact I get the following in all cases (users inside or outside Windows domain):

   - The browser send: GET <entry point 1>

   - In Tomcat

       - SPNEGO generates 401

       - Tomcat redirects the 401 to my "entry point 2"

       - Tomcat replies with "entry point 2" contents without the "Authorization: Negotiate" header

       - the browser display the "entry point 2" asking the user to enter the user and password values.

Artur

Feb 23, 2011 at 6:41 PM

My problem is that I can't modify the application, I don't have the src, So I'm just able to work with tomcat realm. :(

 

Coordinator
Feb 24, 2011 at 2:05 PM

Hello,

Could you add a jsp on your application? Could you use Tomcat 7?

With tomcat 7, the servlets have the new method login(username,password). This method calls the method authenticate of the Realm and then the method register of the Authenticator. So, I am writing the method authenticate of the class WindowsRealm. The users with an AD account, could be authenticated with login/password.

 

Dominique

Feb 24, 2011 at 3:32 PM

Hello,

Unfortunately no,

Actually I'm working with Tomcat6 and can't change, but if you have a new jar, I can try on a Tomcat 7 if my servlet is ok under this new environment

Coordinator
Feb 27, 2011 at 10:12 AM

Hello,

I shall send a new version before the 15th march.
carbonejf: I will add the possibility to use the method login in a servlet or jsp. So with a 401, you could be redirect to a jsp calling this method. I could add the possibility to use the method BASIC to authenticatethe users. So, if the browser choose this method, your users could be authenticated. Are you interesred?

artur(asilveira): Do you  use JNA or TCP with Negoserver? I could send a tomcatspnego beta for tomcat 7 and an example with a 401 customised page.

Dominique

Feb 27, 2011 at 3:22 PM

Yes it coul'd be a solution for me,

Thanks

Mar 1, 2011 at 11:30 AM
Hello Dominique,

Actually I'm using jna with tomcat 5.5. But in the future I will try the tcp version. The tcp version is interesting to cover some few of our customers that uses Linux but I don't try it because of lack of my Linux platform and time for it.

Now I'm going to install Tomcat 7 and a new Windows domain, after look for the new "login" method and checks if we can use it for users that are outside the Windows domain.

When your modifications are available and will take immediatly.

Regards

Artur

Le 27/02/2011 11:12, doumeguerin a écrit :

From: doumeguerin

Hello,

I shall send a new version before the 15th march.
carbonejf: I will add the possibility to use the method login in a servlet or jsp. So with a 401, you could be redirect to a jsp calling this method. I could add the possibility to use the method BASIC to authenticatethe users. So, if the browser choose this method, your users could be authenticated. Are you interesred?

artur(asilveira): Do you use JNA or TCP with Negoserver? I could send a tomcatspnego beta for tomcat 7 and an example with a 401 customised page.

Dominique


Coordinator
Mar 14, 2011 at 10:25 PM

Hello,

There is an example, for the versions with JNA and TCP, with an error page that is calling request.login. 
You can also use another Realm with login. To do that, you have to define a realm in  context.xml and define the parameter loginauthenticationwithoutad.

I do not add BASIC, because the RFC does not define the set of characters (UTF-8,ISO-8859-1 or other) and the browsers do not use the same set. And, of course, the server cannot known the set used by the browser. So, if you are French like me, or Polski, there is a problem.

If the method login is not sufficient, I could add a FORM. With a Form, you can define the set of characters. Send a message, if it is necessary.

Dominique  

 

Mar 14, 2011 at 11:20 PM
Hi,

Thank you Dominique about your modifications, but I will be out of my desk (holidays) for near 3 weeks.

I wiil look the code at my return.

Artur



Le 14/03/2011 22:25, doumeguerin a écrit :

From: doumeguerin

Hello,

There is an example, for the versions with JNA and TCP, with an error page that is calling request.login.
You can also use another Realm with login. To do that, you have to define a realm in context.xml and define the parameter loginauthenticationwithoutad.

I do not add BASIC, because the RFC does not define the set of characters (UTF-8,ISO-8859-1 or other) and the browsers do not use the same set. And, of course, the server cannot known the set used by the browser. So, if you are French like me, or Polski, there is a problem.

If the method login is not sufficient, I could add a FORM. With a Form, you can define the set of characters. Send a message, if it is necessary.

Dominique


Apr 8, 2011 at 7:10 AM
Edited Apr 8, 2011 at 7:14 AM

Sorry I don't find your example in the trunk, is it in example or in exampletc7?

And I don't understand your params, I will explain what I want :

If I'm in the domain, autoamtic login. If I have an error (because I'm not in the domain for exemple with a other computer, from home, ... I woul'd like to have a login windows with a form (or merssage box, ...) that ask login/pwd and Tomcat will try to login with AD (like with automatic logon).

So I don't understant "loginauthenticationwithoutad" because I want to use AD (?)

ps if it's easier I can speak french, because I'm not sure I speak english very well :)

 Edit a little later :

Ok I understand, it's because I don't ask the same as asilveira, the problem for me is to logon to the same domain but from outside of the doamin (from home, ...)

doumeguerin wrote:

Hello,

There is an example, for the versions with JNA and TCP, with an error page that is calling request.login. 
You can also use another Realm with login. To do that, you have to define a realm in  context.xml and define the parameter loginauthenticationwithoutad.

I do not add BASIC, because the RFC does not define the set of characters (UTF-8,ISO-8859-1 or other) and the browsers do not use the same set. And, of course, the server cannot known the set used by the browser. So, if you are French like me, or Polski, there is a problem.

If the method login is not sufficient, I could add a FORM. With a Form, you can define the set of characters. Send a message, if it is necessary.

Dominique  

 

 

Coordinator
Apr 8, 2011 at 8:35 PM

Hello,

Test with exampletc7 and tomcat7. If you canot use kerberos or ntlm, you will be redirected to the error401.html page.
This page is a form. You must give your username and your password. You will be authenticated with Logonuser with jna and via 2 NegotiateStreams and pipestreams with TCP. The page error401.jsp must NOT be used in production: it is only for test. If you read the jsp file, you will find a call to login. By default, when  you will be authenticated with Active Directory.

In french: Avec tomcat 7, tester avec l'application exampletc7. Cet exemple existe avec la version utilisant JNA ou celle utilisant TCP. Si vous n'êtes pas authentifié, vous serez redirigé vers error401.jsp. Ce fichier est défini dans le fichier web.xml comme page utilisée par tomcat en cas de code d'état égal à 401( l'utilisateur n'est pas authentifié). 
Il est possible, selon la configuration du navigateur, que ce dernier présente à l'utilisateur une fenêtre (pop-up)  qui demande un compte et mot de passe. Dans ce cas, vous pouvez les fournir  au navigateur qui va alors chercher à s'authentifier via NTLM avec le serveur. En fait, le navigateur a reçu le code statut 401 avec une demande d'authentification avec SPNEGO (Negoriate). Il sait que vous utilisez un compte local. Il cherche donc à obtenir un nom d'utilsateur et un mot de passe pour faire une authentification NTLM , alors que votre poste n'est pas dans AD.
Si vous n'arrivez pas à vous authentifier avec SPNEGO, SSPAUthenticator renvoie 401 sans préciser de méthode d'authentication. Le navigateur affiche alors le contenu de la page renvoyée avec le ciode 401. Si cette page contient du code javascript, il sera exécuté sur le poste client. D'où le formulaire et l'appel de la méthode login dans la page error401.jsp.
Avec le paramètre  loginauthenticationwithoutad ( authentification sans AD) , vous devez, bien entendu, utiliser un autre Realm (par example JNDIRealm, JDBCRealm ou MemoryRealm). Dans votre cas vous n'indiquez pas ce paramètre, puisque les comptes sont définis dans AD.

Remarque: Si vous utilisez une authentication via nom et mot de passe, quelqu'un de mal intentionné pourrait faire  une attaque de force brute en testant automatiquement différents mots de passe. Pour éviter ce genre d'attaque, bloquez vos comptes après un nombre d'essais infructueux de s'authentifier (par exemple 5 ou 10). Mais alors vous risquez un déni de service parceque vos comptes sont bloqués. Le mieux est donc de bloquer seulement temporairement vos comptes (pendant par exemple 15 minutes). Ceci est vrai non seulement pour AD mais pour tout répertoire de comptes.
Vous pouvez chercher la documentation sur LockoutRealm dans tomcat ( http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html). Mais ceci peut n'être qu'une fausee protection si il y a plusieurs façon de donner son nom (par exemple avec des minuscules des majuscules ...): il est donc préférable de  définir une politique de vérouillage des mots de passe sur le répertoire lui-même.

Warning.:
The login et and the password can be read on the network. If you are on Internet, you MUST use SSL.
Tomcat send a cookie. This cookie can be read on the network. So it can be stolen.  

Attention: Le nom de l'utilisateur et son mot de passe passe en clair sur le réseau. Donc chiffrer le transport avec SSL (https). De même, les cookies passent en clair. Ils peuvent donc être réutilisés par une personne malfaisante. Tomcat utilise la session dont l'identifiant correspond au numéro renvoyé par le cookie.
Sur un réseau peu (ou pas du tout) sûr, utilisez toujous SSL dès qu'il y a confidentialité. (S'il n' y a pas de confidentialité, vous ne demanderiez pas aux utilisateurs de s'authentifier). Si vous ne savez pas utiliser SSL, je pourrai vous donner des informations sur le sujet. Il est toujours possible d'obliger Tomcat à utiliser SSL sur une zone protégée en utilisant une contrainte de confidentialité:

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

Si vous avez encore des problèmes vous pouvez bien sûr envoyer un message.

Dominique