tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Oun <ra...@ounism.com>
Subject Re: Help with SPNEGO Pass-Through
Date Fri, 04 May 2018 11:50:34 GMT
As an update, the override code worked.  Thanks for the guidance.

Here is the code we packaged in a jar and place in the server lib:

package company.catalina.realm;

import java.security.Principal;
import org.apache.catalina.realm.GenericPrincipal;
import org.apache.catalina.realm.NullRealm;

public class NoAuthRealm extends NullRealm {
   @Override
   protected Principal getPrincipal(String username) {
       return new GenericPrincipal(username, null, null);
   }
}

It would be good for this information to be updated on the Tomcat Windows Authentication How-To
docs to help others along.

I also think a Tomcat patch/feature to implement a new Realm for SPNEGO/CLIENT-CERT is a good
idea.  +1

Thanks again for your help!

Randy

> On Apr 25, 2018, at 6:51 AM, Mark Thomas <markt@apache.org> wrote:
> 
> On 25/04/18 03:29, Randy Oun wrote:
>> Thanks Mark.  I adjusted the web.xml for the application to match your
>> recommendation and I'm still getting a HTTP 401 even though I see the
>> WWW-Authenticate header in the request.
>> 
>> I'm still getting the same error as described earlier:
>> 
>> 
>> [org.apache.catalina.realm.UserDatabaseRealm] 17-Apr-2018 11:15:25.407 FINE
>> [https-jsse-nio-8443-exec-7]
>> org.apache.catalina.realm.CombinedRealm.authenticate Failed to authenticate
>> user [USER@DOMAIN.ORG <mailto:USER@DOMAIN.ORG>] with realm
>> 
>> What other info can I provide?
> 
> I think you have provided all the information needed. It is me that hasn't.
> 
> You are going to need to specify a Realm for authenticated users to be
> validated against. You can either configure the JNDI Realm to
> authenticate your users against the MS directory or you could write a
> simple custom Realm (see NullRealm for an example) that does something like:
> 
>    @Override
>    protected Principal getPrincipal(String username) {
>        return new GenericalPrincipal(username, null, null);
>    }
> 
> For authentication mechanisms that essentially validate the user (I'm
> thinking CLIENT-CERT, SPNEGO) we might consider some sort of Realm
> implementation that returns a Principal for any provided user name
> without further validation.
> 
> Mark
> 
> 
>> 
>> On Tue, Apr 24, 2018 at 7:51 AM Mark Thomas <markt@apache.org> wrote:
>> 
>>> On 23/04/18 12:27, Randy Oun wrote:
>>>> Currently I'm configuring Tomcat 8.5 with Integrated Windows
>>>> Authentication/SPNEGO and have a question on proper roles in security
>>>> and auth contraints.  I have completed the instructions in the
>>>> Integrated Windows Authentication doc
>>>> (https://tomcat.apache.org/tomcat-8.5-doc/windows-auth-howto.html) and
>>>> it appears the Kerberos handshake is working.
>>>> 
>>>> The difficulty comes when applying security contraints to an
>>>> application which previously had none applied.  The application uses
>>>> it's own form based authentication system and does not rely upon
>>>> Tomcat's user database mechanisms.  The intent was to write custom
>>>> code in the application to use the Kerberos ticket for single sign-on.
>>>> 
>>>> The main question: is it possible to bypass or pass-through the
>>>> Kerberos header without having Tomcat enforce security or auth
>>>> contraints while enabling SPNEGO?  If so, what is the proper config?
>>>> 
>>>> Ultimately we want to trust to the Kerberos token and avoid any
>>>> unnecessary re-authentication.  I've tried advice from many articles
>>>> online with no success.
>>> 
>>> I'm not completely sure what you are looking for but I think following
>>> will help:
>>> 
>>> - Configure the web application to use SPNEGO authentication
>>> 
>>> <login-config>
>>>  <auth-method>SPNEGO</auth-method>
>>>  <realm-name>SPNEGO Realm</realm-name>
>>> </login-config>
>>> 
>>> - Configure the web application to require authorisation for all
>>>  resources and accept any authenticated user as authorised
>>> 
>>> <security-constraint>
>>>  <display-name>Require user authentication only</display-name>
>>>  <web-resource-collection>
>>>    <web-resource-name>Everything</web-resource-name>
>>>    <url-pattern>/*</url-pattern>
>>>  </web-resource-collection>
>>>  <auth-constraint>
>>>    <role-name>**</role-name>
>>>  </auth-constraint>
>>> </security-constraint>
>>> 
>>> You can then obtain the authenticated Principal via getUserPrincipal()
>>> 
>>> If you cast the principal to TomcatPrincipal you can call
>>> getGssCredential()
>>> 
>>> HTH,
>>> 
>>> Mark
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>> 
>>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org <mailto:users-unsubscribe@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org <mailto:users-help@tomcat.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message