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 <ma...@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 [u...@domain.org <mailto:u...@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 <ma...@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-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> <mailto:users-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: users-h...@tomcat.apache.org
> <mailto:users-h...@tomcat.apache.org>
