RE: Problem enabling SSLv3 in Tomcat 8.5.15

[Marc Dorsa]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, June 21, 2017 2:31 PM
To: Tomcat Users List 
Subject: Re: Problem enabling SSLv3 in Tomcat 8.5.15

On 21/06/17 19:04, Marc Dorsa wrote:
>> Hi Tomcat Users,
>>
>> I am having a difficult time trying to enable SSLv3 in Tomcat 8.5.15.  (A 
>> 3rd-party component of our product requires SSLv3 and there's no getting 
>> around it!)  Our Tomcat is running on a custom Linux distribution based on 
>> Centos 7, and we're running Java 1.8.0_131.  Note that I've already (and 
>> correctly) enabled SSLv3 support in the JVM and verified that SSLv3 is 
>> correctly enabled when running our existing Tomcat 7.0.47.  My guess is that 
>> I have an incorrect server.xml configuration (for Tomcat 8), but the Tomcat 
>> documentation 
>> (https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support) as I 
>> read it, seems to say that simply setting the "protocols" attribute of the 
>> SSLHostConfig element to include "SSLv3" should do the job.
>>
>> Thank you in advance for any help offered!
> 
> 8.5.x and 9.0.x are hard-coded not to allow SSLv2 or SSLv3.
> 
> The docs need to be updated to reflect that. Also the migration guide.
> 
> I've done some svn archaeology and this change was introduced during 
> the refactoring that added support for SNI, ALPN and multiple certificates.
> Originally, the removal of SSLv2 and SSLv3 was only for the default 
> protocols (as it currently is in 8.0.x and earlier). During the 
> refactoring, the filtering effectively switched to applying to the 
> supported protocols.
> 
> A warning is logged during start-up that an unsupported protocol has 
> been requested.
> 
> Tomcat 8.0.x and 7.0.x will continue to support SSLv3 assuming the JVM 
> used also supports it.
> 
> Given the inherent insecurities in SSLv3, I don't like the message 
> re-enabling sends. On the other hand, it drives me mad when software 
> blocks something because it thinks it knows best rather then letting 
> me judge the risk and make the decision for myself.
> 
> I'm therefore leaning towards allowing SSLv3 to be requested but 
> logging a clear warning if it is.
> 
> Mark
> --
> 
> Thank you Mark for clarifying that SSLv3 is *not* supported (at all) 
> in Tomcat 8.5+.  Wow, if only I had known that (via the Tomcat docs), 
> I could have saved days of research and experimentation. :-(

SSLv3 will be available (not by default and using it will result in a warning 
in the logs) from 9.0.0.M23 and 8.5.17 onwards (i.e. not the releases currently 
in progress but the next ones in around a month's time).

Mark
--

Hi Mark,

When can we expect a Tomcat 8.5.x release with SSLv3 support re-enabled?  (This 
feature is critical for our product and is needed ASAP.)

Thank you,
Marc

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat8 - How to configure ssl certificates for both https and two-way authentication

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Senthil,

On 8/8/17 4:03 PM, dsenthil...@gmail.com wrote:
> 
>> Hello,
>> 
>> I have configured ssl certificates for below requirements:
>> 
>> 1. Tomcat server certificate configuration in 'server.xml' file
>> to run tomcat server on port 443 and https
>> 
>> > minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
>> disableUploadTimeout="true" acceptCount="100" scheme="https"
>> secure="true" SSLEnabled="true" clientAuth="false" 
>> sslProtocol="TLSv1.2" ciphers="TLS_RSA_WITH_AES_256_CBC_SHA256"
>> keystoreFile="Tomcat.HostName.pfx" keystorePass="password" 
>> keystoreType="PKCS12" />
>> 
>> 2. Service certificate configuration in 'setenv.sh' file for the
>> two-way ssl authentication for the connection to MQ / Soap
>> service servers.
>> 
>> export JAVA_OPTS='-Djavax.net.ssl.keyStore=ServiceCertificate.p12
>> -Djavax.net.ssl.keyStorePassword=password
>> -Djavax.net.ssl.trustStore=clienttruststore.jks
>> -Djavax.net.ssl.trustStorePassword=changeit'
>> 
>> 
>> But It looks like the service certificate configured (for the
>> two-way ssl handshake with MQ and Soap service servers) in
>> 'setenv.sh' file is overwriting the tomcat server ssl
>> configuration configured in 'server.xml' and subsequently tomcat
>> server is down for https and port 443.
>> 
>> Can someone recommend suitable tomcat config to fix this issue.
>> The tomcat config should support both https (port 443) and
>> two-ways ssl handshake with other servers.

Regardless of the actual problem and solution, here, I would always
highly recommend that you use explicit configuration for your
 for your truststore as well as our keystore. Using system
properties is very heavy-handed and ends up applying the same trust
store to a whole variety of components, not just the .

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmKOlgACgkQHPApP6U8
pFiIvRAArbBwixXhAxxgegBWYIrCMxtqgg8KAccfRyvkmSIGOkQ/xMV+Z8sP+2Xr
KHEnK8P2vKDzgGKT7fjAaD0HCTbWK7j455OKRKYXxowZkOU5Qbz10xW1j25bHtUy
3mD2Vn5jmrv/vMEkr0sJ3AxB8QeyyZ/ZpK33Zy0bNMYB945H3QQ3QX5lX6d8k9El
0VSt4NKglYdLXvuYmI/YVBvIZw0rzt9hPjBAO9Mc0cIEGJfNJafMKjdYpFSfoUOs
b5TpvVEszEGwgsaaOU4Y7EyHg72EAyNtUzyeSIbn0s0VsvYWS3AqT7QiL5GUvQ4Z
glLdYL+34R1gfsB462fE0RFgVaUuGEBUFs/YxV3loh2FUkCe91MbJ02OTRK27Z/o
ipKXNzcwPJ6ASafMRc2qBR6Wt0Mwg+FC/tXIlMcIhVBbkCXNUuhs21n0lO13kdJM
7uK7XSWWTjHyXd38b1NhplidNmDygzTzJ2lcEs/7MDf1lzU0h4l46FbvWNbInDw7
OvvWjheDKH8mqmCNDgbj7iA+b3FMoSwE+Xv5qG54k1nwoStAWzeTFi4vjqHNMxEa
VzKQMcIa++31/Ytdp7UElixMeGwQfxSGJluWi2wnXmupC/+h2YXM3TwG3hgv3t1H
SHQeBUXtnsITpy5iSka1Y2efhEL26jIiApsPIl+TUOLcvumlTrc=
=Bz/F
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat8 - How to configure ssl certificates for both https and two-way authentication

[Mark Thomas]

On 08/08/17 21:03, dsenthil...@gmail.com wrote:
> 
>> Hello,
>>
>> I have configured ssl certificates for below requirements:
>>
>> 1. Tomcat server certificate configuration in 'server.xml' file to run 
>> tomcat server on port 443 and https
>>
>>  > minSpareThreads="25"
>>maxSpareThreads="75" enableLookups="false" 
>> disableUploadTimeout="true"
>>acceptCount="100" scheme="https" secure="true" 
>> SSLEnabled="true" clientAuth="false"
>>sslProtocol="TLSv1.2" 
>> ciphers="TLS_RSA_WITH_AES_256_CBC_SHA256" keystoreFile="Tomcat.HostName.pfx" 
>> keystorePass="password"
>>keystoreType="PKCS12" />
>>
>> 2. Service certificate configuration in 'setenv.sh' file for the two-way ssl 
>> authentication for the connection to MQ / Soap service servers.
>>
>> export JAVA_OPTS='-Djavax.net.ssl.keyStore=ServiceCertificate.p12 
>> -Djavax.net.ssl.keyStorePassword=password 
>> -Djavax.net.ssl.trustStore=clienttruststore.jks 
>> -Djavax.net.ssl.trustStorePassword=changeit'
>>
>>
>> But It looks like the service certificate configured (for the two-way ssl 
>> handshake with MQ and Soap service servers) in 'setenv.sh' file is 
>> overwriting the tomcat server ssl configuration configured in 'server.xml' 
>> and subsequently tomcat server is down for https and port 443.
>>
>> Can someone recommend suitable tomcat config to fix this issue. The tomcat 
>> config should support both https (port 443) and two-ways ssl handshake with 
>> other servers.

Tomcat version?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat8 - How to configure ssl certificates for both https and two-way authentication

[dsenthil . in]

> Hello,
> 
> I have configured ssl certificates for below requirements:
> 
> 1. Tomcat server certificate configuration in 'server.xml' file to run tomcat 
> server on port 443 and https
> 
>   minSpareThreads="25"
>maxSpareThreads="75" enableLookups="false" 
> disableUploadTimeout="true"
>acceptCount="100" scheme="https" secure="true" 
> SSLEnabled="true" clientAuth="false"
>sslProtocol="TLSv1.2" 
> ciphers="TLS_RSA_WITH_AES_256_CBC_SHA256" keystoreFile="Tomcat.HostName.pfx" 
> keystorePass="password"
>keystoreType="PKCS12" />
> 
> 2. Service certificate configuration in 'setenv.sh' file for the two-way ssl 
> authentication for the connection to MQ / Soap service servers.
> 
> export JAVA_OPTS='-Djavax.net.ssl.keyStore=ServiceCertificate.p12 
> -Djavax.net.ssl.keyStorePassword=password 
> -Djavax.net.ssl.trustStore=clienttruststore.jks 
> -Djavax.net.ssl.trustStorePassword=changeit'
> 
> 
> But It looks like the service certificate configured (for the two-way ssl 
> handshake with MQ and Soap service servers) in 'setenv.sh' file is 
> overwriting the tomcat server ssl configuration configured in 'server.xml' 
> and subsequently tomcat server is down for https and port 443.
> 
> Can someone recommend suitable tomcat config to fix this issue. The tomcat 
> config should support both https (port 443) and two-ways ssl handshake with 
> other servers.
> 
> Thanks,
> Senthil
>  

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Access to source IP address during authentication and authorization

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Zemian,

On 8/8/17 9:36 AM, Zemian Deng wrote:
> Hi, how about extends the 
> "org.apache.catalina.authenticator.AuthenticatorBase"? or extends 
> "FormAuthenticator" if you are using form based. The base class is
> actually a Valve, thus provide the "Request" object access. And to
> use it, just simply add as a valve in your context xml file. If I
> understand it correctly, this will override the default one.

I'm trying to come up with a more pluggable solution, like I did with
the CredentialHandlers.

Obviously, I can simply write or extend whatever Valve I want and do
anything with it, but having to choose a single type of authenticator
isn't very flexible.

I'd prefer a solution that improves Tomcat for the whole community,
rather than one that merely meets my private needs.

- -chris

> On Tue, Aug 8, 2017 at 9:09 AM, Mark Thomas 
> wrote:
> 
>> On 08/08/17 14:01, Christopher Schultz wrote:
>>> Mark,
>>> 
>>> On 8/8/17 8:49 AM, Mark Thomas wrote:
 On 08/08/17 13:44, Christopher Schultz wrote:
>>> 
 
>>> 
> I have no problem with Tomcat having access to the IP
> address. I just want Tomcat to make that IP address
> available to the authenticator component in some way.
>>> 
 https://bz.apache.org/bugzilla/show_bug.cgi?id=59750
>>> 
 Implementing that in a way that is truly backwards
 compatible requires a little thought.
>>> 
>>> I agree that backward-compatibility is a significant issue,
>>> since the Realm interface hasn't changed since ... well, ever.
>>> 
>>> How about cheating and using a ThreadLocal?
>>> 
>>> try { tl.set(theRequest) 
>>> authenticator.authenticate(username,password); } finally { 
>>> tl.set(null); }
>>> 
>>> ??
>> 
>> Yuck.
>> 
>>> For SecurityFilter, we added a sub-interface that adds more
>>> methods, like this:
>>> 
>>> authenticate(String username, String password); 
>>> authenticate(String username, String password,
>>> HttpServletRequest req);
>>> 
>>> Then, the driver does this:
>>> 
>>> if(realm instanceof ExtendedRealm) 
>>> ((ExtendedRealm)realm).authenticate(username, password,
>>> theRequest); else realm.authenticate(username, password);
>> 
>> That could work for 8.5.x and earlier. We can use default methods
>> in Tomcat 9.
>> 
>> I was also thinking about the case where a custom component
>> called the Realm (e.g. custom nested Realms). I'm not sure there
>> is one solution that can cleanly handle all use cases. We
>> probably need to go with the majority.
>> 
>>> If using the HttpServletRequest itself is architecturally
>>> distasteful, we could use some other kind of data object, or
>>> simply java.lang.Object (which is a little distasteful
>>> itself).
>> 
>> I have no problem with using the HttpServletRequest.
>> 
>> Mark
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmKD0AACgkQHPApP6U8
pFj78Q//UPwFI0H/Ixbix31lMcK819yiRxDMJJ5aMFkg/JchZJBm6eoJ3pJwP8nF
W9LD/x9qF3tNFc+N3fATUOKi9NWHEnMXxKqWm0OzSmGeM7V1XnaT8hUjA5Mm97He
Io4YSVncq4bG7rb5asyK0+p0zqLZGxPZMeAe+2tM0uvoy06YELJaV6Ra9is8tVtS
CncQYJlDTTHT0ecsbIBUQiC46daYEIbaF0yxU0z794cEN4yAd17jlFmFpQs+7eAT
wNy9eCAlG+Q7w15/rea50QniER+NDGdbXGz6Vpyp42MSy2Zr19cXZQMqlWVrQV3t
Od7C8pjzNIRUHFPFeFX21jfeLReFmTioDXlHrwnayy8WsecYHq2iVkMdEpm7NxY2
etGg26RKPypiLepA3cwj4tUR6lmgE9A7ydP7utY2IfOKU6QZ0vyCz5KITELq+yqf
XG2i/RvI/U7qutXqk5nbkkEH6UCsN9eQrCtKZ4r5tLxIJDlSLSsgsHrUKKdd1zJ8
ACHSKMEA1HyA8pbI7mdENeogNWz1dQ3J7JSpWjHmsEcPutn2dP4Q25+StjkuFAah
W1neqzXrT/Vt/K98Q3mS3YK8/x+X91TS46C2J6zut76KDRHqBAwiXDNq+KFzKePR
+SzBiHS6elz4tXz+zxRG+stmL96ooDMUMJMzDSPSCqGPzmC3jvQ=
=YgBR
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Access to source IP address during authentication and authorization

[Zemian Deng]

Hi, how about extends the
"org.apache.catalina.authenticator.AuthenticatorBase"? or extends
"FormAuthenticator" if you are using form based. The base class is actually
a Valve, thus provide the "Request" object access. And to use it, just
simply add as a valve in your context xml file. If I understand it
correctly, this will override the default one.

On Tue, Aug 8, 2017 at 9:09 AM, Mark Thomas  wrote:

> On 08/08/17 14:01, Christopher Schultz wrote:
> > Mark,
> >
> > On 8/8/17 8:49 AM, Mark Thomas wrote:
> >> On 08/08/17 13:44, Christopher Schultz wrote:
> >
> >> 
> >
> >>> I have no problem with Tomcat having access to the IP address. I
> >>> just want Tomcat to make that IP address available to the
> >>> authenticator component in some way.
> >
> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=59750
> >
> >> Implementing that in a way that is truly backwards compatible
> >> requires a little thought.
> >
> > I agree that backward-compatibility is a significant issue, since the
> > Realm interface hasn't changed since ... well, ever.
> >
> > How about cheating and using a ThreadLocal?
> >
> > try {
> >   tl.set(theRequest)
> >   authenticator.authenticate(username,password);
> > } finally {
> >   tl.set(null);
> > }
> >
> > ??
>
> Yuck.
>
> > For SecurityFilter, we added a sub-interface that adds more methods,
> > like this:
> >
> > authenticate(String username, String password);
> > authenticate(String username, String password, HttpServletRequest req);
> >
> > Then, the driver does this:
> >
> > if(realm instanceof ExtendedRealm)
> >   ((ExtendedRealm)realm).authenticate(username, password, theRequest);
> > else
> >   realm.authenticate(username, password);
>
> That could work for 8.5.x and earlier. We can use default methods in
> Tomcat 9.
>
> I was also thinking about the case where a custom component called the
> Realm (e.g. custom nested Realms). I'm not sure there is one solution
> that can cleanly handle all use cases. We probably need to go with the
> majority.
>
> > If using the HttpServletRequest itself is architecturally distasteful,
> > we could use some other kind of data object, or simply
> > java.lang.Object (which is a little distasteful itself).
>
> I have no problem with using the HttpServletRequest.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Access to source IP address during authentication and authorization

[Mark Thomas]

On 08/08/17 14:01, Christopher Schultz wrote:
> Mark,
> 
> On 8/8/17 8:49 AM, Mark Thomas wrote:
>> On 08/08/17 13:44, Christopher Schultz wrote:
> 
>> 
> 
>>> I have no problem with Tomcat having access to the IP address. I
>>> just want Tomcat to make that IP address available to the
>>> authenticator component in some way.
> 
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59750
> 
>> Implementing that in a way that is truly backwards compatible
>> requires a little thought.
> 
> I agree that backward-compatibility is a significant issue, since the
> Realm interface hasn't changed since ... well, ever.
> 
> How about cheating and using a ThreadLocal?
> 
> try {
>   tl.set(theRequest)
>   authenticator.authenticate(username,password);
> } finally {
>   tl.set(null);
> }
> 
> ??

Yuck.

> For SecurityFilter, we added a sub-interface that adds more methods,
> like this:
> 
> authenticate(String username, String password);
> authenticate(String username, String password, HttpServletRequest req);
> 
> Then, the driver does this:
> 
> if(realm instanceof ExtendedRealm)
>   ((ExtendedRealm)realm).authenticate(username, password, theRequest);
> else
>   realm.authenticate(username, password);

That could work for 8.5.x and earlier. We can use default methods in
Tomcat 9.

I was also thinking about the case where a custom component called the
Realm (e.g. custom nested Realms). I'm not sure there is one solution
that can cleanly handle all use cases. We probably need to go with the
majority.

> If using the HttpServletRequest itself is architecturally distasteful,
> we could use some other kind of data object, or simply
> java.lang.Object (which is a little distasteful itself).

I have no problem with using the HttpServletRequest.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Access to source IP address during authentication and authorization

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/8/17 8:49 AM, Mark Thomas wrote:
> On 08/08/17 13:44, Christopher Schultz wrote:
> 
> 
> 
>> I have no problem with Tomcat having access to the IP address. I
>> just want Tomcat to make that IP address available to the
>> authenticator component in some way.
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59750
> 
> Implementing that in a way that is truly backwards compatible
> requires a little thought.

I agree that backward-compatibility is a significant issue, since the
Realm interface hasn't changed since ... well, ever.

How about cheating and using a ThreadLocal?

try {
  tl.set(theRequest)
  authenticator.authenticate(username,password);
} finally {
  tl.set(null);
}

??

For SecurityFilter, we added a sub-interface that adds more methods,
like this:

authenticate(String username, String password);
authenticate(String username, String password, HttpServletRequest req);

Then, the driver does this:

if(realm instanceof ExtendedRealm)
  ((ExtendedRealm)realm).authenticate(username, password, theRequest);
else
  realm.authenticate(username, password);

If using the HttpServletRequest itself is architecturally distasteful,
we could use some other kind of data object, or simply
java.lang.Object (which is a little distasteful itself).

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmJthYACgkQHPApP6U8
pFhwTw//ZjwS5MtDL7F18OWFrmtxvfyCDbnOiOgwyJxoCCn//xWjQC7sCmb8OZZd
PFnbbzRcU55Ws1+oDz+rZGoXTz8bOOaE0WXQ9r477ETryzjlTNarVgselgQUM24X
zl0cSAMJo4U/fabTrSupSOk1H6OJUwNRI0N4FNYsjpk+mXlScGcZsjycvB6CH5Bp
8ht3J222Q9hdBNatcpLzicfRW5t+smckA+1wxFWBye1gxnG9aaNakcXa/V7nQtoq
nZO636HIvK16LWoudBXUOfHqGTCBYTijfzD37v8LrIsYj6+yJ/ZetkF45tS4nWcF
Gl1vzQQCwY92xd9q6i6UBlnngI898Pp+vuld+mHHwM1nP2dvskO5A4VdYZ+dS4dp
QmMWYKhR4cr2TjOpDKy9hxzuRxeENt1Bnr3Jk2Qiy4o8e0a/e7ksB3JfXS99JfLt
uCprKNMkRG3Uc1+5vZXOQ1kk7Fz1Bryp7xrxgZjXdpHZ1R7GFIgPi6ohbA+GT4NV
dCgYWOPdh1TIcAgOP6dVgHc1H58BX2IjPl8AiKOKLZPKLv+3eWeA5XBz0D1LM0bm
CZ+EwFXCfIr5cFqabvbE99DdojhpT6NPmDjTmJznAV7f8AWHLnyr7eYMQY+pkHdF
GX3oOwzBlw46CVtMnkgu0OrLPnM/X8447RgMs1bJFJ1dpYO0rr8=
=d9LJ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Access to source IP address during authentication and authorization

[Mark Thomas]

On 08/08/17 13:44, Christopher Schultz wrote:



> I have no problem with Tomcat having access to the IP address. I just
> want Tomcat to make that IP address available to the authenticator
> component in some way.

https://bz.apache.org/bugzilla/show_bug.cgi?id=59750

Implementing that in a way that is truly backwards compatible requires a
little thought.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Access to source IP address during authentication and authorization

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Markus,

On 8/8/17 8:21 AM, i...@flyingfischer.ch wrote:
> 
> Am 08.08.2017 um 14:05 schrieb Christopher Schultz:
>> All,
>> 
>> In spite of my (somewhat) recent work on the CredentialHandlers,
>> I haven't been using Tomcat's container-provider authentication
>> and authorization for over a decade. This is because I need
>> access to the user's source IP address for auditing where users
>> "are" when they login to my applications.
>> 
>> Is there any opportunity to obtain the user's IP address during
>> login? IIRC, the JASPIC scheme does allow this kind of
>> information, but I'm not sure if Tomcat actually supplies it.
>> JASPIC is a rather complicated solution when I am in fact
>> authenticating against a simple relational database.
>> 
>> What might be other ways to obtain the user's IP address during 
>> authentication?
>> 
>> Thanks, -chris
>> 
>> PS I don't use Spring, to "just use Spring security like
>> everyone else" isn't a great solution for me.
> 
> If you run Tomcat only you may use request.getRemoteAddr() in the
> logic and build IP based access management around this.

Have you noticed that Tomcat only passes two String values to the
authenticators? The IP address is not available.

> If you run Apache in front of Tomcat you may need to fiddle with 
> X-Forwarded-For header.

I have no problem with Tomcat having access to the IP address. I just
want Tomcat to make that IP address available to the authenticator
component in some way.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmJskcACgkQHPApP6U8
pFivdA//XSyx5+ZszII0hxLjaeJi5+PHTOnbrzdcKLD+Q/6aDeFDbiECQItqAPZY
w30aEWsqEdXiXEiCoHqD7NrsxkL6cM01uPpLSHsISDnPxX69ogWGCZNmxduLUxr2
V3kTLn+s2fry2ZECZWW28KW3aKvs9EQ8bPrxQoPZFHWlXSloIy+ao4UlpxBuCQh2
CO1akIYcxiOXCb8Bq4zIk70/E6zTDnWrsXcu3voTcSV8xrScZxYmj3AKMWITICw8
owmwJ0aQfnnOCs1j7HDz9TEKjUa/Net+Z1d1ZlWlq7aq3xaTBLyDyZskE1FeZ6yK
pZPgveRdmlnReUJYHBfZqqUKT7iPRSoogcHdFZhVyI8JU2ega2nyI+uBDvc6fcPL
PAjBvmZ+FdIk9Plvptv0oc4BzZMd0401JPmuA02CtmqYxfVToJGYuqo4SYiVl5gG
mhCEY+VAIo5LWSRxM3scp/7fe9kj2c/Zn5AcYhNHIm16YEWYGe+FOKrPOMwK67e5
FWj0OxL0pSv9If7MRJ/xMXJyapH3KYkeNY2x5mdXpaueDmpDGb6Hvh9978q8P7wI
xXxfdocDCCFJOgsn7o+GZo4yqnWK177bmYXm2WxzW9AhTVqe285D0XK5OvL1EiAG
RzZqh3IgCNDgYoWzQjGtYO9q9FM4cu6REDBdmZOK8Kn2+fGaxC0=
=fAU7
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Access to source IP address during authentication and authorization

[tomcat]

On 08.08.2017 14:21, i...@flyingfischer.ch wrote:


Am 08.08.2017 um 14:05 schrieb Christopher Schultz:

All,

In spite of my (somewhat) recent work on the CredentialHandlers, I
haven't been using Tomcat's container-provider authentication and
authorization for over a decade. This is because I need access to the
user's source IP address for auditing where users "are" when they
login to my applications.

Is there any opportunity to obtain the user's IP address during login?
IIRC, the JASPIC scheme does allow this kind of information, but I'm
not sure if Tomcat actually supplies it. JASPIC is a rather
complicated solution when I am in fact authenticating against a simple
relational database.

What might be other ways to obtain the user's IP address during
authentication?

Thanks,
-chris

PS I don't use Spring, to "just use Spring security like everyone
else" isn't a great solution for me.


If you run Tomcat only you may use request.getRemoteAddr() in the logic
and build IP based access management around this.

If you run Apache in front of Tomcat you may need to fiddle with
X-Forwarded-For header.

Markus



+1, I was just going to mention the same.
In case of any front-end proxy, getRemoteAddr() would probably give the IP of 
the proxy.
And to make matters a little bit more complicated, see this article :
https://github.com/eprints/eprints/issues/214
This is perl, not Java, but it provides some additional information which might be useful 
(about nginx and HTTPS e.g.)




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Access to source IP address during authentication and authorization

[i...@flyingfischer.ch]

Am 08.08.2017 um 14:05 schrieb Christopher Schultz:
> All,
>
> In spite of my (somewhat) recent work on the CredentialHandlers, I
> haven't been using Tomcat's container-provider authentication and
> authorization for over a decade. This is because I need access to the
> user's source IP address for auditing where users "are" when they
> login to my applications.
>
> Is there any opportunity to obtain the user's IP address during login?
> IIRC, the JASPIC scheme does allow this kind of information, but I'm
> not sure if Tomcat actually supplies it. JASPIC is a rather
> complicated solution when I am in fact authenticating against a simple
> relational database.
>
> What might be other ways to obtain the user's IP address during
> authentication?
>
> Thanks,
> -chris
>
> PS I don't use Spring, to "just use Spring security like everyone
> else" isn't a great solution for me.

If you run Tomcat only you may use request.getRemoteAddr() in the logic
and build IP based access management around this.

If you run Apache in front of Tomcat you may need to fiddle with
X-Forwarded-For header.

Markus




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Access to source IP address during authentication and authorization

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

In spite of my (somewhat) recent work on the CredentialHandlers, I
haven't been using Tomcat's container-provider authentication and
authorization for over a decade. This is because I need access to the
user's source IP address for auditing where users "are" when they
login to my applications.

Is there any opportunity to obtain the user's IP address during login?
IIRC, the JASPIC scheme does allow this kind of information, but I'm
not sure if Tomcat actually supplies it. JASPIC is a rather
complicated solution when I am in fact authenticating against a simple
relational database.

What might be other ways to obtain the user's IP address during
authentication?

Thanks,
- -chris

PS I don't use Spring, to "just use Spring security like everyone
else" isn't a great solution for me.
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmJqRoACgkQHPApP6U8
pFiyBRAAy0hn69+toHp5Dl0mKXlnAFsicOMko95/a8831o75v6/8t5DTIjnU0oAr
G4fND3OW4Ud4XPRnuUVY6u5we7BjQbySDgKdm3Tsa0h36UOUqbP5avzOWAZJMaBX
w0vq97Nn5jCUbiDyM2BABfph3WXk93yBjklfg7p12NlBMu6uR+0de/GPeb8dn/TT
Grdk7NSvDKUn69uqi3alNDyvPqS2F0XPizVgdnEbH6X+9DBBHaK0NSEtT+3D5YaS
WKwjZFubxU8BCO4wb8BLynJy61Fu7CGNQTxg9qI9+sa1kHEuq/XXl++qCVRF6ORJ
ZSd7ujBP9JV7v8WGgDhAZDfZ6HBYvgHr0euXzfqZPRxsqk5tKwz6uvpOgeuNz/Bv
xgOYZrqSw5G+BSj0Ia9k5Gwx4rPldwZ+LKfQ3sUVeg08R+vBePimhMU0oHlh8js8
zC+PaK8EQ0OWkScqCRgMD1B8K1CfR/mQrdoXvvS3e4NP7+gbiyvVLPEIOExlu0cy
zEseknq41o8Iooil4dHB15YZ7JE7TriKDAo/PxSGmvjownRKpTKvXTyBLVTHjudt
vyWtOpJxjaNaos9JeHRkKr7Lx029cxcJt9jJS1Ucatv5n68PCSzN0wDvqZaCEPpS
EUjpo3K+wRq+/BFfRK1K/0m3fGqfAQZT21rmIM011348Lk6s1Go=
=smRC
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [8.0.44] NPE when deploying to /manager/text/list with RemoteHostValve

[Martynas Jusevičius]

Hmm, strange. I tried "ping jenkins" from shell and it worked.
On Tue, 8 Aug 2017 at 04.19, Zemian Deng  wrote:

> Hi Martynas, you are getting NPE because "request.getRemoteHost()" is
> returning null value after you enableLookups! Maybe you have problem
> resolving hostname in your env? Try to disable the valve and test "<%=
> request.getRemoteHost() %>" in a simple jsp until you can get the right
> value before re-enable the valve again.
>
> --Zemian
>
> On Mon, Aug 7, 2017 at 11:46 AM, Martynas Jusevičius <
> marty...@atomgraph.com
> > wrote:
>
> > Hi,
> >
> > I'm deploying WAR from Jenkins Docker container to Tomcat Docker
> container.
> >
> > In server.xml I have enableLookups to enable DNS lookups
> >
> >  >connectionTimeout="2"
> >redirectPort="8443"
> >enableLookups="true"/>
> >
> > and in conf/Catalina/localhost/manager.xml I have
> >
> >  >  docBase="${catalina.home}/webapps/manager">
> >>  allow="jenkins" />
> > 
> >
> > There is also manager-script role and user in tomcat-users.xml but I
> won't
> > post it because authentication works.
> >
> > The issue is RemoteHostValve. If I comment the Valve out, deployment
> works.
> > If I enable it as shown here, in the localhost log I can see
> >
> > 07-Aug-2017 17:00:22.854 SEVERE [http-apr-8080-exec-1]
> > org.apache.catalina.core.StandardHostValve.invoke Exception Processing
> > /manager/text/list
> >  java.lang.NullPointerException
> > at java.util.regex.Matcher.getTextLength(Matcher.java:1283)
> > at java.util.regex.Matcher.reset(Matcher.java:309)
> > at java.util.regex.Matcher.(Matcher.java:229)
> > at java.util.regex.Pattern.matcher(Pattern.java:1093)
> > at
> > org.apache.catalina.valves.RequestFilterValve.isAllowed(
> > RequestFilterValve.java:377)
> > at
> > org.apache.catalina.valves.RequestFilterValve.process(
> > RequestFilterValve.java:312)
> > at
> >
> org.apache.catalina.valves.RemoteHostValve.invoke(RemoteHostValve.java:84)
> > at
> > org.apache.catalina.core.StandardHostValve.invoke(
> > StandardHostValve.java:141)
> > at
> > org.apache.catalina.valves.ErrorReportValve.invoke(
> > ErrorReportValve.java:79)
> > at
> > org.apache.catalina.valves.AbstractAccessLogValve.invoke(
> > AbstractAccessLogValve.java:620)
> > at
> > org.apache.catalina.core.StandardEngineValve.invoke(
> > StandardEngineValve.java:88)
> > at
> > org.apache.catalina.connector.CoyoteAdapter.service(
> > CoyoteAdapter.java:502)
> > at
> > org.apache.coyote.http11.AbstractHttp11Processor.process(
> > AbstractHttp11Processor.java:1132)
> > at
> > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.
> > process(AbstractProtocol.java:684)
> > at
> > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.
> > run(AprEndpoint.java:2458)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1142)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:617)
> > at
> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
> > TaskThread.java:61)
> > at java.lang.Thread.run(Thread.java:748)
> >
> >
> > Can anyone explain what the issue is and how to fix it?
> >
> > Thanks
> >
> > Martynas
> >
>

Re: Getting user role membership without context

[Mark Thomas]

Personally, I'd step through the JNDIRealm with a debugger (I use
Eclipse) to see exactly what is going on. If you aren't set up for that,
enabling debug logging for the JNDIRealm should provide some insight but
it might not answer everything.

Mark


On 04/08/17 21:24, Alex O'Ree wrote:
> Rehashing this. "Works" was working with the out of the box
> tomcat-users.xml file. When incorporating a JNDI/Ldap setup, I'm not
> getting the expected result.
> 
> Server.xml setup
> Realm
> - UserLockOutRealm
> -- JDNIRealm
> -- UserRoleRealm (paraphrasing here, this is the default xml file thing)
> 
> Consider the following ldap setup (MS active directory)
> -LdapUserBob, memberOf=GroupAdmins,GroupNotRelevant objectclass=user
> -GroupAdmins, objectclass=group
> -GroupUsers, objectclass=group
> -GroupNotRelevant, objectclass=group
> 
> In the war/WEB-INF/web.xml, i have the user constraint setup with
> mappings from the ldap groups to application roles.
> Everything works as expected when logging in as LdapUserBob. The
> mapped roles resolve in this context and the application requires the
> mapped role GroupAdmins. LdapUserBob can get in, no one else can
> though (expected)
> 
> Using my hack job reflection solution and stepping through the code, I
> can get a user object from the realm representing LdapUserBob and the
> user object has exactly one role attached to it, GroupNotRelevant. I'm
> a bit unclear as to why only the non relevant group is added to the
> user role. When calling isUserInRole from the servlet context, it's
> returning false. I'm assuming there's something wrong with the JNDI
> realm configuration but since it works correctly under normal
> circumstances and not using the reflection solution, I'm a bit puzzled
> and am unsure how to proceed.
> 
> 
> On Wed, Jul 19, 2017 at 11:20 AM, Alex O'Ree  wrote:
>> Got it to work! Thanks Mark!
>>
>> On Wed, Jul 19, 2017 at 10:40 AM, Mark Thomas  wrote:
>>> On 19/07/17 15:34, Alex O'Ree wrote:
 Context.findChild and findChildren returns an instance of "Container".
 It looks like StandardWrapper extends Container, so I should be able
 to type cast it. The question is, is it always going to be an instance
 of StandardWrapper?
>>>
>>> For a Context, it should always be an instance of Wrapper so as long as
>>> you cast to Wrapper, you should be fine.
>>>
>>> In a default Tomcat install it will always be StandardWrapper but better
>>> to use the interface here since it has the method you need.
>>>
>>> Mark
>>>
>>>

 On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas  wrote:
> On 18/07/17 23:21, Alex O'Ree wrote:
>> Nice, any idea which method I need to call?
>
> You already have the Context so you want
>
> Context.findChildren()
>
> for a list of all the Wrappers (and it is the wrapper object you need) or
>
> Context.findChild(String)
>
> for a specific Wrapper if you know the name. The name should be the name
> used in web.xml to define the Servlet.
>
> Mark
>
>
>>
>> On Jul 18, 2017 3:54 PM, "Mark Thomas"  wrote:
>>
>>> On 18/07/17 17:41, Alex O'Ree wrote:
 Alright, quick update on this.

 At this point, I have servlet context and a username running off the
 main tomcat http threads (quartz job)

> StandardContext tomcat;load from reflection from 
> ApplicationContext
>>> from ServletContext as ApplicationContextFacade
> Realm realm = tomcat.getRealm()

 At this point, realm is a LockoutRealm that contains two child realms,
 the JNDI Realm and the standard UserDatabaseRealm

> Principal user = realm.authenticate(username);

 At this point, the user object is populated and appears to have the
 roles attached to it (they are listed in the to String method).

> realm.hasRole(new StandardWrapper(), user, role);

 This part returns false, if and only if the ldap membership matches
 exactly. Mapped roles via servlet/security-role-ref/role-link and
 role-name do not appear to be effect.

 I think this may have something to do with the Principal object not
 having a login context. Normally, this is available via a servlet, but
 this it is not.

 I think the root cause might be this line.
 https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/
>>> java/org/apache/catalina/realm/RealmBase.java#L933

 Which probably does the translation from the LDAP defined group or
 role into what the application is expecting. Am I on the right path
 here?
>>>
>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>> Servlet won't apply. If you know which servlet to use for the role
>>> mappings you can 

Re: DeltaManager implementation

[Mark Thomas]

On 04/08/17 20:55, christop...@baus.net wrote:
> We are still having an issue with some users losing session information.
> I want to use synchronous updates for the DeltaManager.
> To enable this should the channelSendOptions be set to 6? That isn't
> clear to me from reading the documentation.

Correct. With channelSendOptions 6, the replication message will be sent
at the end of the request processing and the request will not complete
until the message has been received and processed by the other nodes.

Mark


> Thanks,
> -Chris 
> 
> 
> On Thu, Jul 27, 2017, at 12:37 PM, christop...@baus.net wrote:
 Or does the DeltaManager replicate to all nodes?
>>>
>>> It does, but the issue is one of timing. The main problematic area is>> the 
>>> user agent being directed to another node before the session data>> has 
>>> replicated. This can be avoided by configuring sync replication
>>> (which slows things down since the response does not complete
>>> until the>> replication has completed).
>>>
>>
>> I figured out our issue today. Our servers are multi-honed and the
>> multi-cast routing was slightly different on different nodes, so they> 
>> weren't discovering each other.  Explicitly specifying the
>> interface to> bind to in the Membership configuration solved the issue.
>>
>> -> 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