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