Re: Improve logging in org.apache.catalina.filters.RestCsrfPreventionFilter ?

2021-09-19 Thread Polina Georgieva
Hi Chris,

Thanks a lot for the hints!
Here is my PR: https://github.com/apache/tomcat/pull/452

Best Regards,
Polina

On Sat, Aug 28, 2021 at 12:52 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Polina,
>
> On 8/26/21 10:48, Polina Georgieva wrote:
> > Currently the RestCsrfPreventionFilter is responding with 403 response
> when
> > the csrf token sent in the request is different from the one stored in
> the
> > session.
> >
> > However except the 403 response code visible in the http access log file,
> > there’s no indication what happened and why is the error response.
> >
> > So I think introducing some logs in this filter would be beneficial at
> > least from two points of view:
> >
> > 1. Troubleshooting
> >
> > It would be easier to troubleshoot problems with clients that did not
> > integrate with the csrf prevention mechanism properly or could give more
> > clues for other situations - for example cases of session invalidation
> > (done by other filter for example) before the request reaches the filter.
> > Currently such requests are also responded with 403 though the client
> seems
> > to have sent valid session cookie and  csrf token. That’s why I believe
> it
> > would be of great help to add log(s) stating:
> >
> > - if the requested session is found
> > - if there’s token stored in it
> > - if there’s token and session cookie sent in the request
> >
> > without revealing their actual values or other security sensitive data.
> >
> > And this information could be logged only in cases of 403 responses, i.e.
> > would appear only when needed.
> >
> > 1. Improve identifying/tracking security related incidents
> >
> > According to OWASP guidelines it’s recommended to have probable malicious
> > attacks indicated in the logs to better identify security incidents. For
> > more details please refer to [1].
> >
> >
> >
> > If you agree with these ideas, I’ll be happy to propose a patch?
>
> This sounds like a great idea. The RestCsrfPreventionListener and its
> superclass CsrfPreventionListenerBase both have access to a log object
> via the getLogger() method. It would be trivial to:
>
> 1. Add logging for whatever situation you'd like to log
> 2. Configure a logger to direct the output of the CSRF failures wherever
> you'd like
>
> So I think you don't need to worry too much about the logging
> *mechanism* but instead simply add calls to the existing logger.
>
> I was surprised to see *zero* logging in these classes, and adding such
> logging would certainly be a welcome improvement.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: reporting a problem with LDAP auth to Windows Active Directory with Kerberos using the default spnegoDelegationQop="auth-conf" value for Tomcat 9.0.31 and 9.0.52

2021-09-19 Thread Michael Osipov

Am 2021-09-14 um 18:23 schrieb Tim Miller Dyck:

Hello,

I wanted to report an issue with Tomcat LDAP user authentication lookups with 
Tomcat container Kerberos security that I found in our environment when 
upgrading to version Tomcat 9.0.52 from 9.0.30 and what configuration settings 
bypassed the problem.

Here is our base pre-Tomcat upgrade configuration which was working for both 
LDAP user authentication and with Kerberos-enabled authentication (e.g. with 
the Tomcat Manager app).


   *   Tomcat 9.0.30 running on Windows Server 2019
   *   Microsoft OpenJDK packaging, build 11.0.12+7 64-bit
   *   Tomcat is authenticating users using LDAP queries to Windows Server 
2012R2 Active Directory controllers
   *   Tomcat server.xml LDAP configuration:

 


   *   We have some web apps that use Tomcat container Kerberos authentication, 
e.g. we configure the Tomcat Manager app WEB-INF\web.xml with


   

   

 

 SPNEGO

 Tomcat Manager Application

   

The same configuration was then upgraded to Tomcat 9.0.52 with otherwise all 
the same overall configuration in place (Kerberos settings, Java settings, cert 
settings, etc.).

The following problem then appeared when trying to log into the Manager app 
using SPNEGO/Kerberos (and also our web apps using Tomcat container Kerberos 
authentication).


From the Tomcat stderr file:



14-Sep-2021 07:00:32.196 SEVERE [https-jsse-nio-443-exec-10] 
org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing 
authentication

javax.naming.NamingException: LDAP connection has been closed; remaining name 
'dc=myorg,dc=com'

at java.naming/com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133)

at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:443)

at java.naming/com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:639)

at java.naming/com.sun.jndi.ldap.LdapClient.search(LdapClient.java:562)

at java.naming/com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2014)

at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873)

at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798)

at 
java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)

at 
java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)

at 
java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341)

at 
java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)

at org.apache.catalina.realm.JNDIRealm.getUserBySearch(JNDIRealm.java:1610)

at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1447)

at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1376)

at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2352)

at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2288)

at org.apache.catalina.realm.JNDIRealm.getPrincipal(JNDIRealm.java:2269)

at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:504)

at org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:365)

at org.apache.catalina.realm.LockOutRealm.authenticate(LockOutRealm.java:194)

...

In testing with Tomcat ver. 9.0.52, I found the following:


   *   Using Manager with basic auth but still with LDAP user lookups worked - 
only Kerberos-enabled apps had problems with LDAP auth
   *   Switching our connectionURLs to use non-encrypted LDAP instead of LDAPS 
caused the problem to be resolved and LDAP+Kerberos to work again so it was 
something to do with use of SSL with LDAP (but we only want to use LDAPS, of 
course, for security)
   *   In the LDAP server.xml configuration, as per Tomcat documentation, these 
two settings are the defaults if not otherwise specified:

useDelegatedCredential="true"

spnegoDelegationQop="auth-conf "

  *   As per documentation, these settings cause a users's Kerberos 
credentials to be used for the LDAP lookup (if Kerberos credentials are 
available to Tomcat) instead of the specific LDAP connection username and 
password in the JNDIRealm configuration.
   *   I tried setting stripRealmForGss="false" (the default is true, where the 
domain is stripped from the username) - but has the same problem with both true and false 
settings
   *   I tried adding only the line spnegoDelegationQop="auth" and this caused 
the problem to be resolved with Kerberos+LDAP working again
  *   The options for spnegoDelegationQop are auth-conf (default, "authentication plus integrity and 
confidentiality protection"), auth-int ("authentication plus integrity") and auth 
("authentication only").
  *   I also tried auth-int, but this had the same 
"org.apache.catalina.realm.JNDIRealm.getPrincipal Exception performing 
authentication" error
   *   I then tested by adding only the line useDelegatedCredential="false" and 
this also caused the problem to be resolved with Kerberos+LDAP working again 

AW: JASPIC AuthConfigProvider packaged with the web application not found

2021-09-19 Thread Keil, Matthias (ORISA Software GmbH)
Hello everyone and thanks for the hints.
They also work as expected and I can package the provider in the web 
application .

Nevertheless, the Configuration Reference 
(https://tomcat.apache.org/tomcat-9.0-doc/config/jaspic.html) suggests that you 
define your own provider in jaspic-providers.xml and Tomcat will then find it.

I am really only interested in a separate server auth module (SAM). Since I saw 
no way in the documentation to pack this into the web application. That's why I 
tried the way through the provider.

As I said, your suggestions work, but there are also a number of additional 
classes needed to provide the actual SAM.
Thank you again

Mit vielen Grüßen

Matthias Keil

-Ursprüngliche Nachricht-
Von: Bernd Schatz  
Gesendet: Freitag, 17. September 2021 09:53
An: users@tomcat.apache.org
Betreff: Re: JASPIC AuthConfigProvider packaged with the web application not 
found

Hi Matthias,


Am 17.09.21 um 09:39 schrieb bernd.sch...@daimler.com:
> From: "Keil, Matthias (ORISA Software GmbH)" 
> To: users@tomcat.apache.org 
> Subject: JASPIC AuthConfigProvider packaged with the web application 
> not found
> 
> I would like to develop an AuthConfigProvider and would like to deploy it 
> together in a web application.
> 
> The Tomcat 9 configuration reference for the AuthConfigProvider indicates 
> that "The implementation may be packaged with the web application or in 
> Tomcat's $ CATALINA_BASE / lib directory."
> 
> The variant with the $ CATALINA_BASE / lib directory works as expected. My 
> class of the AuthConfigProvider is found and instantiated.
> The variant of packing the implementation together with the web application 
> does not work. In this case I get a java.lang.ClassNotFoundException.
[SNIP]

You can register it by using a ServletContextListener (or via CDI):

AuthConfigFactory factory = AuthConfigFactory.getFactory(); 
factory.registerConfigProvider(new AuthProvider(), "HttpServlet", null, "TEST");

--
greets
Bernd





-
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