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] 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
For additional commands, e-mail: users-h...@tomcat.apache.org
