Re: HTTP 400 with Form based authentication

[Sreyan Chakravarty]

I don't understand where did I request the login page directly ? I just put
 as index.jsp and and the error page as
index.jsp?error=true.

So where is my error ?

On Sun, Aug 30, 2015 at 9:54 PM, Mark Thomas  wrote:

> On 29/08/2015 22:16, Sreyan Chakravarty wrote:
> > Okay this is my first try at container based authentication using Realms
> in
> > Tomcat. And things have gone wrong. Here is my login page -:
>
> 
>
>
> > My web.xml security configuration is -:
> >
> > 
> > 
> > TECHERS
> > /teacher/success.jsp
> > GET
> > POST
> > 
>
> Remove the methods. By enumerating methods ONLY those methods are
> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
>
>
> 
>
> > Now when I click on submit I get the following error page in Tomcat -:
> >
> >
> > *HTTP Status 400 - Invalid direct reference to form login page*
> >
> > *message* *Invalid direct reference to form login page*
> >
> > *description* *The request sent by the client was syntactically
> incorrect.*
> >
> >
> > Why is this happening ? Any help would be greatly appreciated.
>
> Because you requested the login page directly. You need to request the
> protected page and Tomcat will handle the redirects.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: How do LockOutRealms work ?

[Sreyan Chakravarty]

In your opinion would a security framework help in doing this ? Like Apache
Shiro ?

On Sun, Aug 30, 2015 at 9:51 PM, Mark Thomas  wrote:

> On 29/08/2015 21:51, Sreyan Chakravarty wrote:
> > Is there any way I can tell the user that what number of login attempt he
> > is on ? While using the LockOutRealm any way to display his login attempt
> > on an html or jsp page ?
>
> With the LockOutRealm as currently written, no.
>
> If you extend it and write some custom code, yes.
>
> I'd think through the risks very carefully before you go down this road.
> Do the benefits to the users out-weight the additional security risks
> this would create?
>
> Mark
>
> >
> > On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Sreyan,
> >
> > On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
>  I am confused with the functioning of LockOutRealms in Tomcat.
> 
>  My questions are as follows-:
> 
> 
>  1. Say user at IP 10.10.10.1 has reached the maximum number of
>  invalid login attempts and is locked out. Now say a user from
>  10.10.10.2 attempts to login, will Tomcat stop him too since he is
>  trying to login for the first time ? If not then how does Tomcat
>  keep track of users that are locked out ? Via there IP's ?
> >
> > If you look at the code [1], you'll see that users are identified by
> > username (or "identifier) and no other factors. So, if you get
> > locked-out from 10.10.10.1, you will also be locked-out from
> > 10.10.10.2. However, the lock-out information is not shared amongst
> > cluster members, so the LockOutRealm really only protects a single
> > member of a cluster.
> >
> > If you need "proper" user-locking, you'll want to mark the user as
> > locked-out in a database or something. You could do that by extending
> > LockOutRealm and taking some other action (such as marking a user as
> > locked in a db) after the registerAuthFailure method completes.
> >
>  2. When a user is locked out what message is displayed ? Can I
>  display a custom HTML page when a user has been locked out ? In
>  other words how much control do I have over the lock out process
>  and what error messages are shown ?
> >
> > It depends upon the type of authenticator you are using. If you use
> > the BasicAuthenticator or DigestAuthenticator, you'll get a 401
> > response, and you can customize what page gets returned with a 401. If
> > you use a FormAuthenticator, you can customize the form-error-page. If
> > you are using an x509Authenticator, you cannot customize anything
> > since the failure occurs at the SSL handshake level.
> >
> > In any case, there does not appear to be a way to tell that the user
> > failed due to too-many-authentication-failures. You could request such
> > as feature, but I would personally think nobody would want to
> > implement it... you don't want to leak-out any information about the
> > authentication process if you don't have to. Failed login = failed
> > login, without further clarification. For a truly secure system, the
> > LockOutRealm should also probably waste some time when a locked-out
> > user is found, to simulate the amount of time it takes to
> > properly-authenticate the user and then fail.
> >
> > Hope that helps,
> > -chris
> >
> > [1]
> > http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
> > /LockOutRealm.java?view=markup
> >>
> >> -
> >> 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
>
>

Re: Designating a home page while using Realms

[Sreyan Chakravarty]

Can you provide a link to the Servlet Spec the to which section you are
referring to.

On Sun, Aug 30, 2015 at 9:55 PM, Mark Thomas  wrote:

> On 29/08/2015 22:26, Sreyan Chakravarty wrote:
> > Okay I have just started to use Realms and container managed
> authentication
> > and I am confused about as how to specify a home page.
>
> Go and read the Servlet spec for how FORM authentication works.
>
> Then read the section on how to specify security constraints.
>
> Mark
>
>
> >
> > Let me explain-:
> >
> > 
> > TECHERS
> > /teacher/success.jsp
> > GET
> > POST
> > 
> >
> > Here the only resource protected is
> >
> > /teacher/success.jsp page
> >
> > Now what if I wanted to add more pages to protect like
> >
> > /teacher/upload.jsp
> >
> > Do I add another  to the same  ? Or
> > do I create another web-resource collection for /teacher/upload.jsp?
> >
> > Also if they are in the same in the  how does
> > Tomcat know to go to /teacher/success.jsp and not /teacher/upload.jsp ?
> >
> > I mean all forms will have "j_security_check" as action, so which page
> do I
> > go to after login if multiple pages are protected ?
> >
> > How do I say that success.jsp is the home page and all other pages are
> > protected but not home pages ?
> >
> > Regards
> > Sreyan Chakravarty
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: How do LockOutRealms work ?

[Ludovic Pénet]

I can't see what would be the risks with being able to explain "This account is 
locked for X minutes"...


I experienced situations where the user calls the first level service desk and 
a ticket goes all its way to someone who can read the server logs and 
understand the issue... Not exactly optimal.

An option to trigger an exception with more details would be great.

Ludovic

Le 30 août 2015 18:21:51 GMT+02:00, Mark Thomas  a écrit :
>On 29/08/2015 21:51, Sreyan Chakravarty wrote:
>> Is there any way I can tell the user that what number of login
>attempt he
>> is on ? While using the LockOutRealm any way to display his login
>attempt
>> on an html or jsp page ?
>
>With the LockOutRealm as currently written, no.
>
>If you extend it and write some custom code, yes.
>
>I'd think through the risks very carefully before you go down this
>road.
>Do the benefits to the users out-weight the additional security risks
>this would create?
>
>Mark
>
>> 
>> On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>> 
>> Sreyan,
>> 
>> On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
> I am confused with the functioning of LockOutRealms in Tomcat.
>
> My questions are as follows-:
>
>
> 1. Say user at IP 10.10.10.1 has reached the maximum number of
> invalid login attempts and is locked out. Now say a user from
> 10.10.10.2 attempts to login, will Tomcat stop him too since he is
> trying to login for the first time ? If not then how does Tomcat
> keep track of users that are locked out ? Via there IP's ?
>> 
>> If you look at the code [1], you'll see that users are identified by
>> username (or "identifier) and no other factors. So, if you get
>> locked-out from 10.10.10.1, you will also be locked-out from
>> 10.10.10.2. However, the lock-out information is not shared amongst
>> cluster members, so the LockOutRealm really only protects a single
>> member of a cluster.
>> 
>> If you need "proper" user-locking, you'll want to mark the user as
>> locked-out in a database or something. You could do that by extending
>> LockOutRealm and taking some other action (such as marking a user as
>> locked in a db) after the registerAuthFailure method completes.
>> 
> 2. When a user is locked out what message is displayed ? Can I
> display a custom HTML page when a user has been locked out ? In
> other words how much control do I have over the lock out process
> and what error messages are shown ?
>> 
>> It depends upon the type of authenticator you are using. If you use
>> the BasicAuthenticator or DigestAuthenticator, you'll get a 401
>> response, and you can customize what page gets returned with a 401.
>If
>> you use a FormAuthenticator, you can customize the form-error-page.
>If
>> you are using an x509Authenticator, you cannot customize anything
>> since the failure occurs at the SSL handshake level.
>> 
>> In any case, there does not appear to be a way to tell that the user
>> failed due to too-many-authentication-failures. You could request
>such
>> as feature, but I would personally think nobody would want to
>> implement it... you don't want to leak-out any information about the
>> authentication process if you don't have to. Failed login = failed
>> login, without further clarification. For a truly secure system, the
>> LockOutRealm should also probably waste some time when a locked-out
>> user is found, to simulate the amount of time it takes to
>> properly-authenticate the user and then fail.
>> 
>> Hope that helps,
>> -chris
>> 
>> [1]
>>
>http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
>> /LockOutRealm.java?view=markup
>>>
>>>
>-
>>> 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

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: Addding User to a Realm

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 8/29/15 4:54 PM, Sreyan Chakravarty wrote:
> Now can you tell me how do I write my own custom credential
> handler. Planning one that uses sCrypt.

Just create a new class that implements the CredentialHandler
interface. Of course, that means you'll have to build against the
Tomcat API and you will also have to put your .class file in a JAR
file in Tomcat's lib/ directory.

If you're writing an scrypt CredentialHandler, consider donating it to
the community.

It's just two methods: mutate(String) and matches(String,String) so it
should be pretty easy to do.

> How can I write it and reference that same CredentialHandler in
> the context.xml like
> 
> 

Take a look at the code for SecretKeyCredentialHandler:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catali
na/realm/SecretKeyCredentialHandler.java?view=markup

That class is mostly accessors and mutators, and the "matches" method
mostly delegates to the parent class's "matches" method (which calls
back to the SKCH's mutate() method). You may be able to get away with
that dispatch strategy and so your class might be as simple as SKCH.

I'm happy to help build this CredentialHandler with you. It was my
plan to build one a while back, but the fact is that the team doesn't
want a compile-time dependency on any particular scrypt library. But
it could be put into the Tomcat wiki in source form, or it's possible
we could put it into a kind of "contributed" directory in svn that
doesn't get built for releases, but is available as source for anyone
to use.

(Also, a bcrypt-based CredentialHandler would be trivial once an
scrypt-based one was done.)

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5GfQAAoJEBzwKT+lPKRYLDEQAMuFbNuUin3iQnEpdc4NF9YO
oWCeK/fLgp9EqhZnId+L7dkMGye1EYOLWg/19wKdxG0eBBknOJxsMibjbjtiZe6y
P/afckEkgYdY5uoZLN4ZcoYnN+p4Ex35SNSS2qmkrrgA0MdFhLq6Os21kiYhvDnC
4GgfKvIVt9T18ryoXCWtYVnP3N2YcLo3YzdDLbOgB1uWVhf6VAiPtjdsnnBArqQu
b1y8POXXlKsIrBFLo5VKykry0r7fh6E/xBGkhBvqfs3zhtZ2dJo6OW1s4RExebJK
uAUUpsa7yCP0QZHIGHcmLj9D7rWY6hxWGc+Az14siMmNDQQpnON+xwf/KxCKCaEw
GR0BEIbA5xsuFUPuIeTXiGiMH0rA9A8aPA/EFP6b+VaGZ5jTife2UYj2LYWKyYOh
V5vKY5sLHNL+9625zGiHVVz1UTJ7oRXQ+BqUrRPZhdequHUiOtxaHhT3D10lNPJ1
BNHtL6rprLOeC3r4z7PcxqoxmWz9zz8+BOvLPwcmT3MUfEFEXDR6xJletE8uhMrF
iaxA5LI+3UDVHFDeMxW9b6up7RfMd+1CC1tOa8LU4uNcd8gkHEf4pGw42uOYPFXo
tkG96A58lxUXCujFxNGPkk2mVdzkMASTreG1mhhFhXu14qT1TY93HshX+lrrMxxI
SkJAIsJdkFSUrR8k0J3v
=zEGV
-END PGP SIGNATURE-

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

Re: Webapp killing entire Tomcat process

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chuck,

On 8/30/15 8:52 PM, Caldarale, Charles R wrote:
>> From: Jerry Malcolm [mailto:techst...@malcolms.com] Subject:
>> Webapp killing entire Tomcat process
> 
>> But in my opinion, no matter what happens in the code, TC
>> shouldn't completely die, correct?
> 
> Nope, it's all one process, and any thread can take it out.
> Running with a security manager reduces the chance, but doesn't
> preclude it.  Simple silliness such as calling System.exit() will
> also stop everything.
> 
>> I guess my question is, do you have any suggestions for anything
>> my code might do that could kill the process?  At least it might
>> give me a start at what to look for.
> 
> The first step is to stop running Tomcat as a service, and instead
> start it from a command prompt using the startup.bat script.  You
> can also attach a debugger this way and watch what's going on, set
> breakpoints, etc.

+1

Having access to stdout/stderr is very helpful. I'm not sure what the
Windows service runner does with those streams, but you ought to find
them and look at the history.

If it's not a System.exit() (which would be very susprising to find in
a web application's code), it's more likely to be something like a JVM
bug or some native component (like tcnative) crashing the JVM.

Even OOME doesn't kill the JVM... it just likely lobotomizes the
application that's currently running within it.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5GihAAoJEBzwKT+lPKRYUb8P/0uvJukA9SJFrWCjwo+FwVAG
eGTJVYbny38xd02+3hNTfXrfVPENzDhwWaTEkvcXUUp3jy/IgEgzQJdfTmVe55PM
sYY5CiFgDSsSYkHZ125k7En3GiIH94pGhL6CojXIvW7Z8oGL0L9WIoPC6QQSjcUc
VYBfcYTY+lCli8lkU6OXbnfAZ8aOJoyuG7SQCffor/5ZHS09tLTCry52J+hTf+ro
K5Fop10Wpk3r7dOUF5hBVC9xk4kJZpiMLxeKdXDfjp10QHF8AeJ5r0B0halTfl4G
GEzboxsAgF/cavktnmUsVrJvarG8mlHl2anvjHegnKPqrU+i0zMRRt5ul/kqZGxI
sEfKZow8jw6n/Bc1KinfeK+C65wQ24rKSEi28hUyFDh6Rve1DvRZn5MsyK2//xpG
6u2mZIQMjW0jbsazRqDbA0YVBiKkUHlI3bHpRBKklC4wQ477KeMiB1AX70l0hocr
3mzjimG6hb4U+Am8lI6MSGjU4djU9Vl8HtlCSDiovldV7GhQInceRRCZL04BHDaG
qLy+G6QqwJyc51d8jDjakP9DqvFFf0x14Z63+Dwog/kmNp33b3sRAMXr0uF8aUIK
4/ZyKULqv1oRk5ZBIRDa++da3ZHDI6YHmrPVIxfH+XHcfG3AqXlPGoOCEQ9txvG6
QKgbLnzjQwOrV/WkAJae
=Y0v/
-END PGP SIGNATURE-

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

Re: How do LockOutRealms work ?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/31/15 6:42 AM, Mark Thomas wrote:
> On 31/08/2015 07:32, Ludovic Pénet wrote:
>> I can't see what would be the risks with being able to explain
>> "This account is locked for X minutes"...
> 
> An attacker performing a brute force attack has zero knowledge.
> They have to guess both user names and passwords. Telling an
> attacker an account is locked tells them: a) they have found a
> valid user so they can concentrate on the password. b) their
> behaviour has been noticed

+1

You also tell them how long they have to wait before they can resume
their brute-force attack without wasting their own time.

> Must better to let a brute force attacker pound away at a locked
> account wasting their resources and probably tripping additional
> security measures (like an IP block) for the excessive failures
> than it is to tell them what they need to do to keep the
> authentication system happy.

+1

If they are trying all passwords between "a" and "" and they
get locked-out after "d", then can just wait 5 minutes and start over
with "e" and keep going. If you tell them nothing, they may try "e"
through "" while being continuously locked-out and not realize
they have guessed the password correctly at some point.

Also, if you tell them after 4 attempts they are locked-out, maybe
they won't trip ay alarms you have rigged to look for suspicious login
attempts. IF you let them pound-away on your authentication system,
you will be more easily able to detect the break-in attempt.

>> I experienced situations where the user calls the first level 
>> service desk and a ticket goes all its way to someone who can
>> read the server logs and understand the issue... Not exactly
>> optimal.
> 
> I agree. That is why most organisations provide self-service
> password reset options that are linked off the login page. After a
> few failed attempts to login the user simple resets their password
> (within whatever rules the organisation requires) and carries on.
> 
>> An option to trigger an exception with more details would be
>> great.
> 
> The details are available in the logs.
> 
> I am -1 (for security reasons) on providing any information at all
> to the end user as to why a login may have failed.

+1 (or is that -1)

Tomcat itself isn't going to divulge this information to the user. If
you want to reduce your own security in this way, it's up to you to
code your application specifically to do so.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5GqbAAoJEBzwKT+lPKRYDPUP/iCdUuJBd+Lmo/2Ar2VwrDrk
lmMXv3iT/7RtNnORHzB4m5MCTnYbXxKW1cjoL8yGWPMUtzX0LdgYd8GpYbEyuL+i
HYgwb1ODOmxhrmunD+wCQ03gu179p/vAoijj+7hPmEEs58p0wrO5DItagqEkzadP
ReM2X+lOpWW7wN70lI/DtOdqTyHnmaht8Vmkp1XHq5v6wD5744jFI97Pg7EPLV6H
4M3tITF63vFP5B1+vd4M/avQiHWvEdFEJKs+W+73281T70FPTaztU8VswAxYk8ch
ezxg/UFOQLdz6TjDESrSa9NX0lluQZrrBXCtTtDOu7jh227UyQtGZQm6tMIsD/iE
Zw/mAiXF647mV1o4F7Q0ZINQAKYNzYTIbncWWGOXO5Byzg4Ju8D1xgtl5KvOiY2h
yG3HNFxUj9+GOgD6+7jaO5woHBf+O8TLZPFdwPWst6AB4q3BQ8JGvKQGrEpWI3mh
4P+ZrJvNY6gh1sXpsjzAVpmV/R+3ehiJq9GpfCelIGIKKAjviCP0ZQWjzdPovBud
KufaJFwHY0+HTPeXYi4k40R0QskQ+JJmmsXaBw8Xl9UhqDUBOYkb0wG1M0CtzjnY
y2xew/rnENYh25Bsn1kt6JRCoSilFSOUVrD6mFf/LQsutKpAxcpg1SwHSHbcTyy0
P7ixw+K1ee+tVJF/ehC6
=zQYd
-END PGP SIGNATURE-

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

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[dmccrthy]

Hi Chris,

To cut a long story short openssl helped. Using openssl -connect showed the
error below. When I added the -tls1 flag the error went away.

2104:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad
record mac:.\ssl\s3_pkt.c:532:

Configuring Tomcat with the JVM parameter below resolved the issue.

-Dhttps.protocols="TLSv1"

This may limit our client Web application but I have very little influence
over the server-side application, so it'll have to do as a solution for
now.

So the issue seems to be a Java handshake error whereby it has a problem
downgrading from TLSv1.2 to TLSv1 during the handshake. Why it works in our
non-prod environment with the same versions of everything is a mystery, but
I can speculate at some difference in underlying O/S settings, or perhaps a
Java bug.

Many thanks for your patience and advice.

Diarmuid
On 28 Aug 2015 20:46, "Christopher Schultz" 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Diarmuid,
>
> On 8/28/15 3:25 PM, dmccrthy wrote:
> > Thanks again for replying. I agree it doesn't look like a Tomcat
> > issue and would be happy to close the issue. I've included
> > responses to your points below prefixed with [DMC] for my initials,
> > but think I need to focus on the Java side of things and perhaps
> > open an Oracle ticket.
>
> Feel free to continue the conversation here. I just marked it as "off
> topic" because it's not directly-related to Tomcat. This could have
> happened in any other application server, for instance.
>
> There's nothing wrong with having an off-topic discussion, here. I
> just wanted everyone to know that this wasn't directly-related to Tomcat
> .
>
> See below.
>
> > On 8/27/15 4:31 PM, dmccrthy wrote:
>  Thanks for responding so quickly. My apologies, I should have
>  been clearer on the topology. We have a Tomcat instance with
>  a 3rd party web app deployed on it (the "Tomcat client")
>  running on Windows 2008 . This connects via HTTPS to a 3rd
>  party service running behind IBM Http Server on Solaris 10.
> >
> > Okay, so, just to confirm:
> >
> > Tomcat (app) -> HTTPS -> 3rd party service
> >
> > Configurations and results:
> >
> > 0. prod Tomcat -> prod 3rd-party service FAILS with
> > TLS_RSA_WITH_AES_128_CBC_SHA
> >
> >> [DMC]  Correct
>
> Ok.
>
> > (do other ciphers work? or are you completely dead in the water?)
> >
> >> [DMC] No, this is the next step. Our production environment is
> >> completely locked down and we have to exhaust all other avenues
> >> before making speculative changes.
>
> I suppose what I meant was: do 100% of your connections to this
> 3rd-party service fail because this one cipher suite seems to be
> broken, or do you have some connections that work and others that do
> not? If some work, do they have anything in common with each other?
>
> > 2. prod Tomcat -> prod 3rd-party service with lower version of
> > Tomcat and/or Java WORKS with TLS_RSA_WITH_AES_128_CBC_SHA
> >
> >> [DMC] Correct
>
> So, downgrading does in fact improve the situation. Can you try
> upgrading Java in one of your working production environments but
> leave Tomcat alone? That would definitely rule-out Tomcat as a problem.
>
> > 1. test Tocmat -> test 3rd-party service WORKS with
> > TLS_RSA_WITH_AES_128_CBC_SHA
> >
> >> [DMC] Correct
>
> Good. What version was this running again? Same Java/Tomcat versions
> as the production server which seems to fail?
>
> > 2. test client (command-line?) on production host -> prod 3rd
> > parts service WORKS with TLS_RSA_WITH_AES_128_CBC_SHA
> >
> >> [DMC] Correct. The command line test client is a simple Java
> >> class that just opens an InputStream to the 3rd party service
>
> So: same Java, same host, same client library: works. But within
> Tomcat on that host with that Java with that same client library:
> fails? :(
>
> > No changes are known/expected, other than Tomcat and Java version.
> >
> >> [DMC] It's a greenfield app and no changes are planned bar
> >> functional patches. The same version of operating system, java,
> >> tomcat, and the application is in our non-prod environment and
> >> works ok
>
> There is obviously a difference. We just have to figure out what it is.
>
> What are your JVM parameters to launch Tomcat? You can find those out
> using "jinfo" from the command-line if you have the process id (at
> least I *think* that works on Windows). Check the running production
> application as well as the CLI client running on the same machine.
> Quadruple-check the Java versions of those processes.
>
>  Two additional pieces of analysis that came out of our
>  investigations today are:
> 
>  1) we are using NextGen Cisco devices. These are application
>  and protocol aware. This means that the firewall might allow
>  allow our standalone Java client to connect using HTTPS, but
>  interfere with the HTTPS SOAP requests from our Tomcat/3rd
>  party app "Tomcat 

Re: Addding User to a Realm

[Sreyan Chakravarty]

Christopher what I am planning to do is getting the source of an open
source sCrypt library and actually copy pasting the source code into the
ScryptCredentialHandler.java. Since I am no security expert.

Now this eliminates the compile time dependency but if the open source
scrypt library is updated then the Handler must be updated accordingly.

Is that a good design plan ?

Also I am confused about how to create the jar. For example I create the
project in eclipse under say a package called test.handler, how do I write
my code so that it becomes a part of org.catalina.realm ?

Regards
Sreyan Chakravarty

On Mon, Aug 31, 2015 at 8:12 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sreyan,
>
> On 8/29/15 4:54 PM, Sreyan Chakravarty wrote:
> > Now can you tell me how do I write my own custom credential
> > handler. Planning one that uses sCrypt.
>
> Just create a new class that implements the CredentialHandler
> interface. Of course, that means you'll have to build against the
> Tomcat API and you will also have to put your .class file in a JAR
> file in Tomcat's lib/ directory.
>
> If you're writing an scrypt CredentialHandler, consider donating it to
> the community.
>
> It's just two methods: mutate(String) and matches(String,String) so it
> should be pretty easy to do.
>
> > How can I write it and reference that same CredentialHandler in
> > the context.xml like
> >
> > 
>
> Take a look at the code for SecretKeyCredentialHandler:
> http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catali
> na/realm/SecretKeyCredentialHandler.java?view=markup
>
> That class is mostly accessors and mutators, and the "matches" method
> mostly delegates to the parent class's "matches" method (which calls
> back to the SKCH's mutate() method). You may be able to get away with
> that dispatch strategy and so your class might be as simple as SKCH.
>
> I'm happy to help build this CredentialHandler with you. It was my
> plan to build one a while back, but the fact is that the team doesn't
> want a compile-time dependency on any particular scrypt library. But
> it could be put into the Tomcat wiki in source form, or it's possible
> we could put it into a kind of "contributed" directory in svn that
> doesn't get built for releases, but is available as source for anyone
> to use.
>
> (Also, a bcrypt-based CredentialHandler would be trivial once an
> scrypt-based one was done.)
>
> Hope that helps,
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV5GfQAAoJEBzwKT+lPKRYLDEQAMuFbNuUin3iQnEpdc4NF9YO
> oWCeK/fLgp9EqhZnId+L7dkMGye1EYOLWg/19wKdxG0eBBknOJxsMibjbjtiZe6y
> P/afckEkgYdY5uoZLN4ZcoYnN+p4Ex35SNSS2qmkrrgA0MdFhLq6Os21kiYhvDnC
> 4GgfKvIVt9T18ryoXCWtYVnP3N2YcLo3YzdDLbOgB1uWVhf6VAiPtjdsnnBArqQu
> b1y8POXXlKsIrBFLo5VKykry0r7fh6E/xBGkhBvqfs3zhtZ2dJo6OW1s4RExebJK
> uAUUpsa7yCP0QZHIGHcmLj9D7rWY6hxWGc+Az14siMmNDQQpnON+xwf/KxCKCaEw
> GR0BEIbA5xsuFUPuIeTXiGiMH0rA9A8aPA/EFP6b+VaGZ5jTife2UYj2LYWKyYOh
> V5vKY5sLHNL+9625zGiHVVz1UTJ7oRXQ+BqUrRPZhdequHUiOtxaHhT3D10lNPJ1
> BNHtL6rprLOeC3r4z7PcxqoxmWz9zz8+BOvLPwcmT3MUfEFEXDR6xJletE8uhMrF
> iaxA5LI+3UDVHFDeMxW9b6up7RfMd+1CC1tOa8LU4uNcd8gkHEf4pGw42uOYPFXo
> tkG96A58lxUXCujFxNGPkk2mVdzkMASTreG1mhhFhXu14qT1TY93HshX+lrrMxxI
> SkJAIsJdkFSUrR8k0J3v
> =zEGV
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP 400 with Form based authentication

[Sreyan Chakravarty]

Wait I am sure I am going wrong in a fundamental area.

My security constraint is as follow-:



TECHERS
/teacher/success.jsp
GET
POST



TEACHER




FORM

/index.jsp
/index.jsp?error=true




TEACHER


Now let me tell you what I understand from this-:


   - The  /teacher/success.jsp is protected via a
   FORM login page that is index.jsp
   - Therefore the page after login which the user will land to is
   /teacher/success.jsp. I don't need to specify that elsewhere.
   -  element designates the login page.
   -  element designates the page to go to if login has
   failed.

This is my understanding of the whole process. Please don't tell me that I
have to put  as /teacher/success.jsp. If so then where do
I designate the login page ?

Forgive my noobishness. Just starting out with servlet security.

Regards
Sreyan Chakravarty

On Mon, Aug 31, 2015 at 3:59 PM, Mark Thomas  wrote:

> On 31/08/2015 07:00, Sreyan Chakravarty wrote:
> > I don't understand where did I request the login page directly ? I just
> put
> >  as index.jsp and and the error page as
> > index.jsp?error=true.
> >
> > So where is my error ?
>
> Did you request '/teacher/success.jsp' ? No, you did not.
>
> Did you request '/index.jsp' (or '/' that because of welcome page
> processing would forward to '/index.jsp') ? Yes, you did. And that is
> your error.
>
> Mark
>
>
> >
> > On Sun, Aug 30, 2015 at 9:54 PM, Mark Thomas  wrote:
> >
> >> On 29/08/2015 22:16, Sreyan Chakravarty wrote:
> >>> Okay this is my first try at container based authentication using
> Realms
> >> in
> >>> Tomcat. And things have gone wrong. Here is my login page -:
> >>
> >> 
> >>
> >>
> >>> My web.xml security configuration is -:
> >>>
> >>> 
> >>> 
> >>> TECHERS
> >>> /teacher/success.jsp
> >>> GET
> >>> POST
> >>> 
> >>
> >> Remove the methods. By enumerating methods ONLY those methods are
> >> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
> >>
> >>
> >> 
> >>
> >>> Now when I click on submit I get the following error page in Tomcat -:
> >>>
> >>>
> >>> *HTTP Status 400 - Invalid direct reference to form login page*
> >>>
> >>> *message* *Invalid direct reference to form login page*
> >>>
> >>> *description* *The request sent by the client was syntactically
> >> incorrect.*
> >>>
> >>>
> >>> Why is this happening ? Any help would be greatly appreciated.
> >>
> >> Because you requested the login page directly. You need to request the
> >> protected page and Tomcat will handle the redirects.
> >>
> >> 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
>
>

RE: HTTP 400 with Form based authentication

[Caldarale, Charles R]

> From: Sreyan Chakravarty [mailto:sreyan.mail...@gmail.com] 
> Subject: Re: HTTP 400 with Form based authentication

> My security constraint is as follow-:
> 
> FORM
> 
> /index.jsp
> /index.jsp?error=true
> 
> 

> This is my understanding of the whole process. Please don't tell me that I
> have to put  as /teacher/success.jsp. If so then where do
> I designate the login page ?

One problem is that you have designated a welcome-file as the login page, 
pretty much forcing an infinite loop if a client doesn't request a specific 
resource.  You want your login page to be completely separate (e.g., login.jsp) 
- it should never be directly referenced by a client.  The server handles the 
replay of the original request once the login has been satisfied.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Diarmuid,

On 8/31/15 11:36 AM, dmccrthy wrote:
> To cut a long story short openssl helped. Using openssl -connect
> showed the error below. When I added the -tls1 flag the error went
> away.
> 
> 2104:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed
> or bad record mac:.\ssl\s3_pkt.c:532:
> 
> Configuring Tomcat with the JVM parameter below resolved the
> issue.
> 
> -Dhttps.protocols="TLSv1"

Yep, you have to use a TLS handshake; the older SSL3 handshake won't wor
k.

Now... you *can* enable SSLv2Hello and then only support TLSv1+, but
let's face it: SSL is dead and clients should get with the program.

> This may limit our client Web application but I have very little
> influence over the server-side application, so it'll have to do as
> a solution for now.

Your client should not try to use SSL handshake unless you know it's
required.

> So the issue seems to be a Java handshake error whereby it has a
> problem downgrading from TLSv1.2 to TLSv1 during the handshake.

I don't know enough about TLS to know if there is an appreciable
difference between the handshake protocol between the two. I know that
SSLv2 was the lowest common denominator for a while, and most servers
would enable it *just for the handshake* but would refuse to actually
negotiate an SSLv2 connection (SSLv2 was basically DOA). These days,
nobody should be using SSL at all, but I might understand wanting to
use SSL-compatible handshakes, so using "SSLv2Hello" but not
supporting the SSLv3 protocol would be the way to do that.

Again, we should just let SSL die. The more we push clients and
servers to only negotiate TLS from here on out, the better off
Internet security will be overall.

> Why it works in our non-prod environment with the same versions of 
> everything is a mystery, but I can speculate at some difference in 
> underlying O/S settings, or perhaps a Java bug.

Or more likely a configuration option you didn't detect when you
checked everything out.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5IudAAoJEBzwKT+lPKRY+xsP/RBgD3VErGPgLZIOu6GDdUn9
4e/yH5kVAdiuOcnn26En+OJKGONK5c9Hf9gW23utPw2ruG1KYwSkr9dJ4yFIiKxh
1wYhq4oTN3j8DwNb8C2Y522eyH9hRYo+W8S7er0pvklcGiImgx+vp/LYitM2dHeG
6MEPJ03+/5CLbrmYfLbcZvnPydqKYVJtIqozHGhrC5+fAbcFFsWBcwrfk0Menwji
wE4w7o5yi38/MtXX1b3FtMnvyjfiKHdPoKJ4PJv8KA3hKjWzEVLiehFGEQGb9VS6
uqgMLB5YR3QrI0yYN53soi4apgqktcfwGimK+B5Ar/2uvsarLvZgIF8uYuEHXTYY
bn+V7ngmRxuwX71VUJDP47MtwQsgxko4H1qa2jIh7Pp8kRHeHwKytJxOLPUepmKp
K1rmii+OtVPMQusXGVJedohXMwOCi3kUf9exmadnN02EgAPmIh/rfy7uBARfYJdC
CqjiQxmTCm5yKu1uB9PXFbZMiCFjq+Hw3g6/cVnn1X5nxlfkPBCAODk5UouRrO+w
oIErBEAbLSb7twWo8S6B9pupb/8C4RNvdhPk9pCfPf2cC+Ouybg4Sz/S4KSQ1N8P
0zfXVoDL4AJtl3k1ylXbfPVRE5SY+ZMqT4fC3odI1frWGI3oSnnXNQsqxr4ehmpo
PUDzJVZbKxLMruMEbnSh
=OrTI
-END PGP SIGNATURE-

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

Re: Addding User to a Realm

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyen,

On 8/31/15 12:23 PM, Sreyan Chakravarty wrote:
> Christopher what I am planning to do is getting the source of an
> open source sCrypt library and actually copy pasting the source
> code into the ScryptCredentialHandler.java. Since I am no security
> expert.
> 
> Now this eliminates the compile time dependency but if the open
> source scrypt library is updated then the Handler must be updated
> accordingly.
> 
> Is that a good design plan ?

No.

I wouldn't do that if I were you for a few reasons:

1. It might violate the license of the library.
2. You won't benefit from updates to the library.
3. You might break the security as you rip it out of one place and
put it into another.
4. You are mingling the separation of concerns of these two pieces
of code: the scrypt library should handle the crypto, and your
CredentialHandler should handle and plumbing necessary for working
with a Tomcat Realm.

That scrypt API should be fairly easy to use, right?

> Also I am confused about how to create the jar. For example I
> create the project in eclipse under say a package called
> test.handler, how do I write my code so that it becomes a part of
> org.catalina.realm ?

You don't. Just make the class
org.sreyan.tomcat.realm.ScryptCredentialHandler and then bundle it in
your own JAR file -- something like myscrypt.jar -- and then put that
JAR file into Tomcat's lib/ directory.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5I1xAAoJEBzwKT+lPKRY/qkP/RApau14EJJBtijnWRhGXzHu
wrcFq+r/scy+QpXNV0/Z+YbZgN4kGcIGZN+EfprybW9CAyoboOzv4v5fEUXJp+I8
6nYYMEP/T3Eirc2j1lpVpWGzJV1orUnP9+/zXDnjI3YwmoIJWCfYfkeJQD58TIbx
3MzY8xwnfpZS+/RzoyoBIzdSrJ0ML2sZdbFtDWUYKNIRkvangw3S/siiQn1/a5w8
RmHRO0Haq/BEA5ONrUFWHJZO82H1eBlEs/hSeqHVdT9dAvxevKk30cEOFgzD79uc
VYu8jgnLAEiuUcsdWdmWw3zCGwXSQRBtkpdYYN6ThD8g/VIEAzHFZPcM9qIF2yfU
14FhVynIm04jindAU7v3Hln7yWxBFb6OrmrjPgLbedzTEF558vHP3L7N1v3nlpzc
bC4Gy7tXarGCRyFvJ7WIR3mAv+Lr2B18k9y1CaLG9SQAxOfQgKp7VEDc76Zdt5t8
z4PBUvzye/OZN73rb86tIX66L+k8/iRI6OsxGX5eYGdnMxy4Vvmaj+C6k0DRQzCF
p2E5nF99OLRAiXelZZkQj4kr9oBPs8V848LjPxaTE8MCZWmsPV4K5BF/yUtKgjGh
y9MdNglCfJz55c73KBNWZd0HNmq/dNs5SsdQr5rOuPnEPcUAIV41c93aE7msDq2X
x5sL/nOE8QWZQNPoWYAQ
=WwFr
-END PGP SIGNATURE-

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

Re: HTTP 400 with Form based authentication

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 8/31/15 12:34 PM, Sreyan Chakravarty wrote:
> Wait I am sure I am going wrong in a fundamental area.
> 
> My security constraint is as follow-:
> 
>   
> TECHERS 
> /teacher/success.jsp 
> GET POST 
> 
> 
>  TEACHER 
>  
> 
>  FORM  
> /index.jsp 
> /index.jsp?error=true 
>  
> 
>  TEACHER 
> 
> Now let me tell you what I understand from this-:
> 
> 
> - The  /teacher/success.jsp is protected
> via a FORM login page that is index.jsp - Therefore the page after
> login which the user will land to is /teacher/success.jsp. I don't
> need to specify that elsewhere. -  element
> designates the login page. -  element designates
> the page to go to if login has failed.
> 
> This is my understanding of the whole process. Please don't tell me
> that I have to put  as /teacher/success.jsp. If so
> then where do I designate the login page ?
> 
> Forgive my noobishness. Just starting out with servlet security.

With your above configuration, you have to point your web browser at
https://yourhost/teacher/success.jsp

This will cause Tomcat to send you to the login page, and you can ener
your username and password. Once you enter the right username and
password, Tomcat will actually send you to /teacher/success.jsp

You really should read the Servlet Spec's section on authentication.
In fact, read the whole spec. It's quite readable and if you are going
to be writing web applications, you really ought to have read it.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5I30AAoJEBzwKT+lPKRYNvUQAIQOP8ShOVFnGkia8kAE2HMO
mDbr7f54havmRECpC2mCbxvIr3YphXMcDBZJpmuD1IS6ybNIa0hzvX/L2hSmxBYA
l2oDgInsm+jX+ndkHfZMtKcYp0Fku1Zg4VbSI13z+kTxObBd3tMN0ngkWGqO8YJC
4lwV62ho+wx0Xg9r7tpHgqjYfLGDBwJiKkKyG47FNbDtkZFp/BukVMY2QJWKwDuj
Jb68wQ90jL4xBBLP6zCaJwpNXYjawAdJCCnFJkm90/6DhGzybnWMMQ736CVYdV/T
64npEeglSytj/KUJlzsO5aCEMK5CZi13D2CYYP2Svh/bGvrlUoHn3sGuAScavgn5
NKT5KdyiXkvXV5YOghTaycje9pXBUkQmhHsIWFMj1vuJOU8E0X+Rl+MJ2fSGrgic
D0x/zM58pUAPKnA2TD8xcUwLCDSo4akqCt64OPZNmM+i2hi2wXYVF4xfKBUD39GV
oau/MeEj4c8xYHoswC/vC3X1Ol2a3Kliubbb1owXIQUEzILCPFf8tfB/awFMwVDj
SfYR7nFtPvkHygqVY15Q38w3bxmobwlV/6Zb4mpmPER/OLQuWfNbdT7z/qVIZ53G
FSOaFfsWOgFFD3mjn1IUezVOjTUSpaTRU5xCIoM6LC7XdOxYLTMFKIyk1rjEEWbh
0+wJHnsU1MbmxszEHMxd
=5ou+
-END PGP SIGNATURE-

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

Re: HTTP 400 with Form based authentication

[Sreyan Chakravarty]

First of all I did read the Servlet Spec, it provided no hint as to what I
was doing wrong.

So you are saying that I can't have a login form on the page when the
welcome page ? Why not ? Tons of site have just that, like Twitter and
Facebook. It seems weird why I can't have it on my welcome page.

And wait a minute. You are telling me that I have to first point my web
browser to /teacher/success.jsp and then when I get the login page and
login  ?


What can't I do the following-:

First login from the login page and then go to success.jsp ?

Why do I have to first hit an auth error and then be redirected back to
login and then provide my user/pass combo ?

So how do you code a login module ? Where I can login first and then go to
my resources ?

This is indeed weird.

On Mon, Aug 31, 2015 at 10:55 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sreyan,
>
> On 8/31/15 12:34 PM, Sreyan Chakravarty wrote:
> > Wait I am sure I am going wrong in a fundamental area.
> >
> > My security constraint is as follow-:
> >
> >  
> > TECHERS
> > /teacher/success.jsp
> > GET POST
> > 
> >
> >  TEACHER
> >  
> >
> >  FORM 
> > /index.jsp
> > /index.jsp?error=true
> >  
> >
> >  TEACHER 
> >
> > Now let me tell you what I understand from this-:
> >
> >
> > - The  /teacher/success.jsp is protected
> > via a FORM login page that is index.jsp - Therefore the page after
> > login which the user will land to is /teacher/success.jsp. I don't
> > need to specify that elsewhere. -  element
> > designates the login page. -  element designates
> > the page to go to if login has failed.
> >
> > This is my understanding of the whole process. Please don't tell me
> > that I have to put  as /teacher/success.jsp. If so
> > then where do I designate the login page ?
> >
> > Forgive my noobishness. Just starting out with servlet security.
>
> With your above configuration, you have to point your web browser at
> https://yourhost/teacher/success.jsp
>
> This will cause Tomcat to send you to the login page, and you can ener
> your username and password. Once you enter the right username and
> password, Tomcat will actually send you to /teacher/success.jsp
>
> You really should read the Servlet Spec's section on authentication.
> In fact, read the whole spec. It's quite readable and if you are going
> to be writing web applications, you really ought to have read it.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV5I30AAoJEBzwKT+lPKRYNvUQAIQOP8ShOVFnGkia8kAE2HMO
> mDbr7f54havmRECpC2mCbxvIr3YphXMcDBZJpmuD1IS6ybNIa0hzvX/L2hSmxBYA
> l2oDgInsm+jX+ndkHfZMtKcYp0Fku1Zg4VbSI13z+kTxObBd3tMN0ngkWGqO8YJC
> 4lwV62ho+wx0Xg9r7tpHgqjYfLGDBwJiKkKyG47FNbDtkZFp/BukVMY2QJWKwDuj
> Jb68wQ90jL4xBBLP6zCaJwpNXYjawAdJCCnFJkm90/6DhGzybnWMMQ736CVYdV/T
> 64npEeglSytj/KUJlzsO5aCEMK5CZi13D2CYYP2Svh/bGvrlUoHn3sGuAScavgn5
> NKT5KdyiXkvXV5YOghTaycje9pXBUkQmhHsIWFMj1vuJOU8E0X+Rl+MJ2fSGrgic
> D0x/zM58pUAPKnA2TD8xcUwLCDSo4akqCt64OPZNmM+i2hi2wXYVF4xfKBUD39GV
> oau/MeEj4c8xYHoswC/vC3X1Ol2a3Kliubbb1owXIQUEzILCPFf8tfB/awFMwVDj
> SfYR7nFtPvkHygqVY15Q38w3bxmobwlV/6Zb4mpmPER/OLQuWfNbdT7z/qVIZ53G
> FSOaFfsWOgFFD3mjn1IUezVOjTUSpaTRU5xCIoM6LC7XdOxYLTMFKIyk1rjEEWbh
> 0+wJHnsU1MbmxszEHMxd
> =5ou+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Addding User to a Realm

[Sreyan Chakravarty]

Yup the API is very easy to but that keeps a compile time dependency. What
I mean is that you also need to put the sCrypt jar into you /lib folder. If
thats okay then things get really easy.

Regards
Sreyan Chakravarty

On Mon, Aug 31, 2015 at 10:52 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sreyen,
>
> On 8/31/15 12:23 PM, Sreyan Chakravarty wrote:
> > Christopher what I am planning to do is getting the source of an
> > open source sCrypt library and actually copy pasting the source
> > code into the ScryptCredentialHandler.java. Since I am no security
> > expert.
> >
> > Now this eliminates the compile time dependency but if the open
> > source scrypt library is updated then the Handler must be updated
> > accordingly.
> >
> > Is that a good design plan ?
>
> No.
>
> I wouldn't do that if I were you for a few reasons:
>
> 1. It might violate the license of the library.
> 2. You won't benefit from updates to the library.
> 3. You might break the security as you rip it out of one place and
> put it into another.
> 4. You are mingling the separation of concerns of these two pieces
> of code: the scrypt library should handle the crypto, and your
> CredentialHandler should handle and plumbing necessary for working
> with a Tomcat Realm.
>
> That scrypt API should be fairly easy to use, right?
>
> > Also I am confused about how to create the jar. For example I
> > create the project in eclipse under say a package called
> > test.handler, how do I write my code so that it becomes a part of
> > org.catalina.realm ?
>
> You don't. Just make the class
> org.sreyan.tomcat.realm.ScryptCredentialHandler and then bundle it in
> your own JAR file -- something like myscrypt.jar -- and then put that
> JAR file into Tomcat's lib/ directory.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV5I1xAAoJEBzwKT+lPKRY/qkP/RApau14EJJBtijnWRhGXzHu
> wrcFq+r/scy+QpXNV0/Z+YbZgN4kGcIGZN+EfprybW9CAyoboOzv4v5fEUXJp+I8
> 6nYYMEP/T3Eirc2j1lpVpWGzJV1orUnP9+/zXDnjI3YwmoIJWCfYfkeJQD58TIbx
> 3MzY8xwnfpZS+/RzoyoBIzdSrJ0ML2sZdbFtDWUYKNIRkvangw3S/siiQn1/a5w8
> RmHRO0Haq/BEA5ONrUFWHJZO82H1eBlEs/hSeqHVdT9dAvxevKk30cEOFgzD79uc
> VYu8jgnLAEiuUcsdWdmWw3zCGwXSQRBtkpdYYN6ThD8g/VIEAzHFZPcM9qIF2yfU
> 14FhVynIm04jindAU7v3Hln7yWxBFb6OrmrjPgLbedzTEF558vHP3L7N1v3nlpzc
> bC4Gy7tXarGCRyFvJ7WIR3mAv+Lr2B18k9y1CaLG9SQAxOfQgKp7VEDc76Zdt5t8
> z4PBUvzye/OZN73rb86tIX66L+k8/iRI6OsxGX5eYGdnMxy4Vvmaj+C6k0DRQzCF
> p2E5nF99OLRAiXelZZkQj4kr9oBPs8V848LjPxaTE8MCZWmsPV4K5BF/yUtKgjGh
> y9MdNglCfJz55c73KBNWZd0HNmq/dNs5SsdQr5rOuPnEPcUAIV41c93aE7msDq2X
> x5sL/nOE8QWZQNPoWYAQ
> =WwFr
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP 400 with Form based authentication

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
> First of all I did read the Servlet Spec, it provided no hint as to
> what I was doing wrong.
> 
> So you are saying that I can't have a login form on the page when
> the welcome page ? Why not ? Tons of site have just that, like
> Twitter and Facebook. It seems weird why I can't have it on my
> welcome page.

Oh, you can do it, but you'll have to implement it yourself. Go
re-read the spec's section on how FORM authentication works. Note that
you are required to attempt to access a protected page before being
asked for authentication. I think it's a big hole in the spec that
should be filled, but anything Tomcat would do for you here is, by
definition, out-of-spec.

> And wait a minute. You are telling me that I have to first point my
> web browser to /teacher/success.jsp and then when I get the login
> page and login  ?

Yes.

> What can't I do the following-:
> 
> First login from the login page and then go to success.jsp?

You sure can do that, but you can't use j_security_check as yourPOST
target. Instead, you have to write your own Servlet and then
(probably) call HttpServletRequest.login() from there, then redirect
the user to wherever you want them to go.

> Why do I have to first hit an auth error and then be redirected
> back to login and then provide my user/pass combo ?

This is spec-defined behavior.

> So how do you code a login module ? Where I can login first and
> then go to my resources ?

What's a "login module"?

> This is indeed weird.

It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But
certainly not weird.

Servlet 3.0 added the HttpServletRequest.login() method would improved
the situation greatly: you can implement your own login handler that
plugs-into the authentication services of the container. It's just
that the container doesn't handle any redirection to a login page
(none is required) or credential capturing (easily done with a servlet).

Really the only thing the servlet spec is missing is a setting in
 like  or something like that, so
that if you try to login with j_security_check and you hadn't already
requested a protected resource, the container knows where to send the
user after authentication.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5JOeAAoJEBzwKT+lPKRYwSgQAJAARzjHnDqMXY9QexbBpyrZ
DSZSxqCRljdHtnEEuBjlLfT8FRUATIU3g0rHZ99SQSXhgYojfvCZ7WalO3izxu6o
NvmbptcCo/rASOvVqtVYpTu1ONhSgGu/v0fZ7maZksMlb0yXUSHpM5EeUucU92NK
AEnZElXlV+6yf2arN9R5L80lZHxioF5tUkS1RoqYsBr3+1KuS1DzfVVO2NKzPLiK
L03QVRCGdDtln66m6lrbPNjgzhMK3HvqMiHAPuED5sTMAha8uk5HTZfM855ojuY4
x8whD7X/6JjTemLue1pzd1CfSGx+EDxrgxgOscFyA4PK0zy8vQWnsnb5MAjKtvdw
+8oHg445RDoYG6BYJ1ZXbTmft9APN37PCeyxzKcGEv0sEzj4q5XRIr8oNiXi74mf
8CQ1QsFv6tlMHysLk/3Tj53AwscZ59xnovjH5lUJqGDi8v6uIojhCOAwzG5UBQF0
JHq6Nd295a3Qp9XTj0WCyDJ6gHyDlzNMivI/dJzkaHOSeyML/hSfYSKKEL1vaOOO
OECSLWqCWiXztOCNCbHvT5YINSmzqV1hdqoPEdSQyLlVbeHrK6vrZVAFpoqoxOOp
ZaliFI6FTZkyiz3KE6pUjMR6PSiiTwK5GW/xhiI2ky5tcBgv4y8ZHXDiTOmchFt4
M5Rksa1BFd+fVbV0tn6m
=u/HP
-END PGP SIGNATURE-

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

Re: Addding User to a Realm

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 8/31/15 1:42 PM, Sreyan Chakravarty wrote:
> Yup the API is very easy to but that keeps a compile time
> dependency. What I mean is that you also need to put the sCrypt jar
> into you /lib folder. If thats okay then things get really easy.

I think having scrypt-whatever.jar in Tomcat's lib/ directory is
definitely okay. I'm just saying that nobody is going to ship the
CredentialHandler with Tomcat because we don't want that dependency
for Tomcat itself.

But for an individual user? It's perfectly fine to do that.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5JPmAAoJEBzwKT+lPKRYSmAQAMCjE/wB61G4pUfySdDQpnzA
ZBLpn/CopHr1BUp9h5F4yQYcMrvJj0JYyeUmyv1QngjgTlPS27Lafi+G42In4A/Q
RrSjOBqzFt2dwy8UCz5+zQXnw1CyxkuTbH5zDMADvvVzOPxfIY13w1xW4XkDf3Gf
09FqkMVKnRZqRXKF8NSPDyjzC7RFa11T9YRooEFfI2voFxuAlj8FzQiqZfn4rl2i
s+PF+fbuX8TI4BfTuy6RVGEIhiTX2+Y4wm8l8RcZr9NfhsBB3Vwmak44NFr3CtRq
fG/sIxWEMrVfqmVzPj63ekLl6ugf3OBF7rjhCmj+IAaZSSEaP6Cy2eUT43Ie4ycR
PtEeLPs/jg8+9m/5w0hB2XdvLLfTY2f/kK9oJvFt4/YbGSluCqPcnOjPJdCsZi0M
x3XRZxVSdMuwnHgFNOZu1FYAB13Dp22tE401hHSi/W/A4obqZ9PE90ZqK/8Lhabg
bMnYLHcL/DRfQusaAsvmFIfVch0nX4Wt7MCMSr+1Wwg/88H04E3VTnEiUF/eKjnZ
RRzdXmdRdlKf7E/ZL/4AazCNrmiystx9+Ax0Guj8dkNhvTvZs93PBjeGvt1U9Vwt
vLFBWPLB2nRPsGXe91jGjNCin1MnY+b/PQ5K0xHYJ+Edcn/j90toIuPbFdNYIAbj
WWQokEts36eAF9Cv9O6F
=Jz7a
-END PGP SIGNATURE-

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

Re: HTTP 400 with Form based authentication

[Mark Thomas]

On 31/08/2015 18:49, Christopher Schultz wrote:

> Really the only thing the servlet spec is missing is a setting in
>  like  or something like that, so
> that if you try to login with j_security_check and you hadn't already
> requested a protected resource, the container knows where to send the
> user after authentication.

And that is a feature Tomcat provides as an extension to the FORM
authenticator.

Mark

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

Re: HTTP 400 with Form based authentication

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/31/15 2:01 PM, Mark Thomas wrote:
> On 31/08/2015 18:49, Christopher Schultz wrote:
> 
>> Really the only thing the servlet spec is missing is a setting
>> in  like  or something like
>> that, so that if you try to login with j_security_check and you
>> hadn't already requested a protected resource, the container
>> knows where to send the user after authentication.
> 
> And that is a feature Tomcat provides as an extension to the FORM 
> authenticator.

Yeah... I thought I remembered doing that but I couldn't find the
reference to it and I'm fairly busy today :)

Thanks for the reference.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV5Jl9AAoJEBzwKT+lPKRYmQEP/2d0tmw48jatl/Q3HoXhSvCn
W13Rr4/7t0GlgxtHfHKzv68XA8EnzvcpWg/aYnN+xSUZ4dbNcdVOjYU6SpR/bDRI
Cg0zLnr/KccTKpd6OuSxzczWSc6OEVviIPthFATb9R6ooPJ/sS3AR5Be6wKjbeCD
yAQZCQXMfBHDd39Zi6FWmWX4D0PJ8xht9Wq7bwrTup5Wpri8VRkQtQWoCzjcWCK5
hxweWqyFy0d0FCUFm+BK1DtoO3OlLpnDLTc1qRENlfrQ+x1aMzb0n77fFI5lKrPw
y4jugfuFgFN/Q3DLAdRgysii6hWLT2Ymt6bIxDYX9QzKNmf12KtwqoeyHxVP4so7
/jUoEqnT4m8Twef6tBZ7XIBWwLJiYTEavA1nalIIa8VMniLb0pZBwfkBD7bA13Ln
fMHfDWEkJ4mADn9cCAzKRXYEAXlOheDpErEtXmLb+RZA/2th+0hgpPo3KzDu4YRq
h7CCvC1/OBNu4WRIC1FBTQoacZHlpol/AWAecXVoHY85349L+UHcpVIrgLMQsKtP
VGJI2aM5oDAiAf2v3AXVXhwvDbuBZfbrbgmiVzviNW9seKtLnz6lAA49uo0sceAf
g6EQj/B3coUWHszmZpCh2W4iiSaEqDMntZl03a2NqwBdTa9+ShbFktOu7JfrX3bo
zuoqrRYFZi25hAE7/Xfw
=8MYf
-END PGP SIGNATURE-

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

Re: HTTP 400 with Form based authentication

[Sreyan Chakravarty]

Well Christopher thanks for that eye opener. I didn't know that the specs
were so inconsistent.

Okay now regarding your comment-:

"Servlet 3.0 added the HttpServletRequest.login() method would improved
the situation greatly: you can implement your own login handler that
plugs-into the authentication services of the container. It's just
that the container doesn't handle any redirection to a login page
(none is required) or credential capturing (easily done with a servlet)."

How do you implement your own login handler and how do you plug that into
Tomcat Auth services. Can you provide some info as to how I would do that ?

And what is the extension to FORM Authenticator that Mark is talking about ?

Also correct me if I am wrong, then the page that I use to login and the
page that will contain j_security_check as an action must be two different
pages.

Also can I have two  elements in my web.xml ?

On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sreyan,
>
> On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
> > First of all I did read the Servlet Spec, it provided no hint as to
> > what I was doing wrong.
> >
> > So you are saying that I can't have a login form on the page when
> > the welcome page ? Why not ? Tons of site have just that, like
> > Twitter and Facebook. It seems weird why I can't have it on my
> > welcome page.
>
> Oh, you can do it, but you'll have to implement it yourself. Go
> re-read the spec's section on how FORM authentication works. Note that
> you are required to attempt to access a protected page before being
> asked for authentication. I think it's a big hole in the spec that
> should be filled, but anything Tomcat would do for you here is, by
> definition, out-of-spec.
>
> > And wait a minute. You are telling me that I have to first point my
> > web browser to /teacher/success.jsp and then when I get the login
> > page and login  ?
>
> Yes.
>
> > What can't I do the following-:
> >
> > First login from the login page and then go to success.jsp?
>
> You sure can do that, but you can't use j_security_check as yourPOST
> target. Instead, you have to write your own Servlet and then
> (probably) call HttpServletRequest.login() from there, then redirect
> the user to wherever you want them to go.
>
> > Why do I have to first hit an auth error and then be redirected
> > back to login and then provide my user/pass combo ?
>
> This is spec-defined behavior.
>
> > So how do you code a login module ? Where I can login first and
> > then go to my resources ?
>
> What's a "login module"?
>
> > This is indeed weird.
>
> It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But
> certainly not weird.
>
> Servlet 3.0 added the HttpServletRequest.login() method would improved
> the situation greatly: you can implement your own login handler that
> plugs-into the authentication services of the container. It's just
> that the container doesn't handle any redirection to a login page
> (none is required) or credential capturing (easily done with a servlet).
>
> Really the only thing the servlet spec is missing is a setting in
>  like  or something like that, so
> that if you try to login with j_security_check and you hadn't already
> requested a protected resource, the container knows where to send the
> user after authentication.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV5JOeAAoJEBzwKT+lPKRYwSgQAJAARzjHnDqMXY9QexbBpyrZ
> DSZSxqCRljdHtnEEuBjlLfT8FRUATIU3g0rHZ99SQSXhgYojfvCZ7WalO3izxu6o
> NvmbptcCo/rASOvVqtVYpTu1ONhSgGu/v0fZ7maZksMlb0yXUSHpM5EeUucU92NK
> AEnZElXlV+6yf2arN9R5L80lZHxioF5tUkS1RoqYsBr3+1KuS1DzfVVO2NKzPLiK
> L03QVRCGdDtln66m6lrbPNjgzhMK3HvqMiHAPuED5sTMAha8uk5HTZfM855ojuY4
> x8whD7X/6JjTemLue1pzd1CfSGx+EDxrgxgOscFyA4PK0zy8vQWnsnb5MAjKtvdw
> +8oHg445RDoYG6BYJ1ZXbTmft9APN37PCeyxzKcGEv0sEzj4q5XRIr8oNiXi74mf
> 8CQ1QsFv6tlMHysLk/3Tj53AwscZ59xnovjH5lUJqGDi8v6uIojhCOAwzG5UBQF0
> JHq6Nd295a3Qp9XTj0WCyDJ6gHyDlzNMivI/dJzkaHOSeyML/hSfYSKKEL1vaOOO
> OECSLWqCWiXztOCNCbHvT5YINSmzqV1hdqoPEdSQyLlVbeHrK6vrZVAFpoqoxOOp
> ZaliFI6FTZkyiz3KE6pUjMR6PSiiTwK5GW/xhiI2ky5tcBgv4y8ZHXDiTOmchFt4
> M5Rksa1BFd+fVbV0tn6m
> =u/HP
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP 400 with Form based authentication

[Sreyan Chakravarty]

Ok I found FormAuthenticator and landingPage attribute in it in the source.
But how do I use that in my application ? What do I do ?

Any documentation for this ?

On Tue, Sep 1, 2015 at 12:46 AM, Sreyan Chakravarty <
sreyan.mail...@gmail.com> wrote:

> Well Christopher thanks for that eye opener. I didn't know that the specs
> were so inconsistent.
>
> Okay now regarding your comment-:
>
> "Servlet 3.0 added the HttpServletRequest.login() method would improved
> the situation greatly: you can implement your own login handler that
> plugs-into the authentication services of the container. It's just
> that the container doesn't handle any redirection to a login page
> (none is required) or credential capturing (easily done with a servlet)."
>
> How do you implement your own login handler and how do you plug that into
> Tomcat Auth services. Can you provide some info as to how I would do that ?
>
> And what is the extension to FORM Authenticator that Mark is talking about
> ?
>
> Also correct me if I am wrong, then the page that I use to login and the
> page that will contain j_security_check as an action must be two different
> pages.
>
> Also can I have two  elements in my web.xml ?
>
> On Mon, Aug 31, 2015 at 11:19 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Sreyan,
>>
>> On 8/31/15 1:39 PM, Sreyan Chakravarty wrote:
>> > First of all I did read the Servlet Spec, it provided no hint as to
>> > what I was doing wrong.
>> >
>> > So you are saying that I can't have a login form on the page when
>> > the welcome page ? Why not ? Tons of site have just that, like
>> > Twitter and Facebook. It seems weird why I can't have it on my
>> > welcome page.
>>
>> Oh, you can do it, but you'll have to implement it yourself. Go
>> re-read the spec's section on how FORM authentication works. Note that
>> you are required to attempt to access a protected page before being
>> asked for authentication. I think it's a big hole in the spec that
>> should be filled, but anything Tomcat would do for you here is, by
>> definition, out-of-spec.
>>
>> > And wait a minute. You are telling me that I have to first point my
>> > web browser to /teacher/success.jsp and then when I get the login
>> > page and login  ?
>>
>> Yes.
>>
>> > What can't I do the following-:
>> >
>> > First login from the login page and then go to success.jsp?
>>
>> You sure can do that, but you can't use j_security_check as yourPOST
>> target. Instead, you have to write your own Servlet and then
>> (probably) call HttpServletRequest.login() from there, then redirect
>> the user to wherever you want them to go.
>>
>> > Why do I have to first hit an auth error and then be redirected
>> > back to login and then provide my user/pass combo ?
>>
>> This is spec-defined behavior.
>>
>> > So how do you code a login module ? Where I can login first and
>> > then go to my resources ?
>>
>> What's a "login module"?
>>
>> > This is indeed weird.
>>
>> It's a (giant, gaping) hole in the spec. Inconvenient, maybe. But
>> certainly not weird.
>>
>> Servlet 3.0 added the HttpServletRequest.login() method would improved
>> the situation greatly: you can implement your own login handler that
>> plugs-into the authentication services of the container. It's just
>> that the container doesn't handle any redirection to a login page
>> (none is required) or credential capturing (easily done with a servlet).
>>
>> Really the only thing the servlet spec is missing is a setting in
>>  like  or something like that, so
>> that if you try to login with j_security_check and you hadn't already
>> requested a protected resource, the container knows where to send the
>> user after authentication.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBCAAGBQJV5JOeAAoJEBzwKT+lPKRYwSgQAJAARzjHnDqMXY9QexbBpyrZ
>> DSZSxqCRljdHtnEEuBjlLfT8FRUATIU3g0rHZ99SQSXhgYojfvCZ7WalO3izxu6o
>> NvmbptcCo/rASOvVqtVYpTu1ONhSgGu/v0fZ7maZksMlb0yXUSHpM5EeUucU92NK
>> AEnZElXlV+6yf2arN9R5L80lZHxioF5tUkS1RoqYsBr3+1KuS1DzfVVO2NKzPLiK
>> L03QVRCGdDtln66m6lrbPNjgzhMK3HvqMiHAPuED5sTMAha8uk5HTZfM855ojuY4
>> x8whD7X/6JjTemLue1pzd1CfSGx+EDxrgxgOscFyA4PK0zy8vQWnsnb5MAjKtvdw
>> +8oHg445RDoYG6BYJ1ZXbTmft9APN37PCeyxzKcGEv0sEzj4q5XRIr8oNiXi74mf
>> 8CQ1QsFv6tlMHysLk/3Tj53AwscZ59xnovjH5lUJqGDi8v6uIojhCOAwzG5UBQF0
>> JHq6Nd295a3Qp9XTj0WCyDJ6gHyDlzNMivI/dJzkaHOSeyML/hSfYSKKEL1vaOOO
>> OECSLWqCWiXztOCNCbHvT5YINSmzqV1hdqoPEdSQyLlVbeHrK6vrZVAFpoqoxOOp
>> ZaliFI6FTZkyiz3KE6pUjMR6PSiiTwK5GW/xhiI2ky5tcBgv4y8ZHXDiTOmchFt4
>> M5Rksa1BFd+fVbV0tn6m
>> =u/HP
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

Re: How do LockOutRealms work ?

[George Sexton]

On 8/31/2015 8:54 AM, Christopher Schultz wrote:
You also tell them how long they have to wait before they can resume 
their brute-force attack without wasting their own time.

Must better to let a brute force attacker pound away at a locked
account wasting their resources and probably tripping additional
security measures (like an IP block) for the excessive failures
than it is to tell them what they need to do to keep the
authentication system happy.




I've started using Fail2Ban because of brute force attacks against 
Postfix-SASL. It would be nice if the LockoutRealm also reported the IP 
address so I could use it to cover Tomcat as well. In it's 
implementation, LockoutRealm gives the user n tries per account (at 
least that's my understanding).


--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: How do LockOutRealms work ?

[Ludovic Pénet]

The points you raise are, of course real and important.
I would probably decide the same as you for a high profile, publicly available 
application.

I however most often have to develop complex apps only used by, at most, 100s 
of corporate users.

I know perimetric security is less and less fashionable but on our intranet, I 
still feel comfortable with more info for the user, ideally coupled with an 
alert to the support team when an account is temporarily locked. 

In the FormAuthenticator valve, you have a parameter to disable session change 
on auth 
https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Form_Authenticator_Valve/Attributes

This enables session fixation attacks, which seems to be a much more serious 
threat to me. ;)

Thanks any way, you gave us pointers on how to implement a custom auth valve, 
which I might end coding.

With kind regards,



Le 31 août 2015 16:54:20 GMT+02:00, Christopher Schultz 
 a écrit :
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Mark,
>
>On 8/31/15 6:42 AM, Mark Thomas wrote:
>> On 31/08/2015 07:32, Ludovic Pénet wrote:
>>> I can't see what would be the risks with being able to explain
>>> "This account is locked for X minutes"...
>> 
>> An attacker performing a brute force attack has zero knowledge.
>> They have to guess both user names and passwords. Telling an
>> attacker an account is locked tells them: a) they have found a
>> valid user so they can concentrate on the password. b) their
>> behaviour has been noticed
>
>+1
>
>You also tell them how long they have to wait before they can resume
>their brute-force attack without wasting their own time.
>
>> Must better to let a brute force attacker pound away at a locked
>> account wasting their resources and probably tripping additional
>> security measures (like an IP block) for the excessive failures
>> than it is to tell them what they need to do to keep the
>> authentication system happy.
>
>+1
>
>If they are trying all passwords between "a" and "" and they
>get locked-out after "d", then can just wait 5 minutes and start over
>with "e" and keep going. If you tell them nothing, they may try "e"
>through "" while being continuously locked-out and not realize
>they have guessed the password correctly at some point.
>
>Also, if you tell them after 4 attempts they are locked-out, maybe
>they won't trip ay alarms you have rigged to look for suspicious login
>attempts. IF you let them pound-away on your authentication system,
>you will be more easily able to detect the break-in attempt.
>
>>> I experienced situations where the user calls the first level 
>>> service desk and a ticket goes all its way to someone who can
>>> read the server logs and understand the issue... Not exactly
>>> optimal.
>> 
>> I agree. That is why most organisations provide self-service
>> password reset options that are linked off the login page. After a
>> few failed attempts to login the user simple resets their password
>> (within whatever rules the organisation requires) and carries on.
>> 
>>> An option to trigger an exception with more details would be
>>> great.
>> 
>> The details are available in the logs.
>> 
>> I am -1 (for security reasons) on providing any information at all
>> to the end user as to why a login may have failed.
>
>+1 (or is that -1)
>
>Tomcat itself isn't going to divulge this information to the user. If
>you want to reduce your own security in this way, it's up to you to
>code your application specifically to do so.
>
>- -chris
>-BEGIN PGP SIGNATURE-
>Comment: GPGTools - http://gpgtools.org
>
>iQIcBAEBCAAGBQJV5GqbAAoJEBzwKT+lPKRYDPUP/iCdUuJBd+Lmo/2Ar2VwrDrk
>lmMXv3iT/7RtNnORHzB4m5MCTnYbXxKW1cjoL8yGWPMUtzX0LdgYd8GpYbEyuL+i
>HYgwb1ODOmxhrmunD+wCQ03gu179p/vAoijj+7hPmEEs58p0wrO5DItagqEkzadP
>ReM2X+lOpWW7wN70lI/DtOdqTyHnmaht8Vmkp1XHq5v6wD5744jFI97Pg7EPLV6H
>4M3tITF63vFP5B1+vd4M/avQiHWvEdFEJKs+W+73281T70FPTaztU8VswAxYk8ch
>ezxg/UFOQLdz6TjDESrSa9NX0lluQZrrBXCtTtDOu7jh227UyQtGZQm6tMIsD/iE
>Zw/mAiXF647mV1o4F7Q0ZINQAKYNzYTIbncWWGOXO5Byzg4Ju8D1xgtl5KvOiY2h
>yG3HNFxUj9+GOgD6+7jaO5woHBf+O8TLZPFdwPWst6AB4q3BQ8JGvKQGrEpWI3mh
>4P+ZrJvNY6gh1sXpsjzAVpmV/R+3ehiJq9GpfCelIGIKKAjviCP0ZQWjzdPovBud
>KufaJFwHY0+HTPeXYi4k40R0QskQ+JJmmsXaBw8Xl9UhqDUBOYkb0wG1M0CtzjnY
>y2xew/rnENYh25Bsn1kt6JRCoSilFSOUVrD6mFf/LQsutKpAxcpg1SwHSHbcTyy0
>P7ixw+K1ee+tVJF/ehC6
>=zQYd
>-END PGP SIGNATURE-
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Re: HTTP 400 with Form based authentication

[Mark Thomas]

On 31/08/2015 07:00, Sreyan Chakravarty wrote:
> I don't understand where did I request the login page directly ? I just put
>  as index.jsp and and the error page as
> index.jsp?error=true.
> 
> So where is my error ?

Did you request '/teacher/success.jsp' ? No, you did not.

Did you request '/index.jsp' (or '/' that because of welcome page
processing would forward to '/index.jsp') ? Yes, you did. And that is
your error.

Mark


> 
> On Sun, Aug 30, 2015 at 9:54 PM, Mark Thomas  wrote:
> 
>> On 29/08/2015 22:16, Sreyan Chakravarty wrote:
>>> Okay this is my first try at container based authentication using Realms
>> in
>>> Tomcat. And things have gone wrong. Here is my login page -:
>>
>> 
>>
>>
>>> My web.xml security configuration is -:
>>>
>>> 
>>> 
>>> TECHERS
>>> /teacher/success.jsp
>>> GET
>>> POST
>>> 
>>
>> Remove the methods. By enumerating methods ONLY those methods are
>> protected. PUT, HEAD, DELETE, etc. aould all be permitted.
>>
>>
>> 
>>
>>> Now when I click on submit I get the following error page in Tomcat -:
>>>
>>>
>>> *HTTP Status 400 - Invalid direct reference to form login page*
>>>
>>> *message* *Invalid direct reference to form login page*
>>>
>>> *description* *The request sent by the client was syntactically
>> incorrect.*
>>>
>>>
>>> Why is this happening ? Any help would be greatly appreciated.
>>
>> Because you requested the login page directly. You need to request the
>> protected page and Tomcat will handle the redirects.
>>
>> 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

Re: Designating a home page while using Realms

[Mark Thomas]

On 31/08/2015 07:01, Sreyan Chakravarty wrote:
> Can you provide a link to the Servlet Spec the to which section you are
> referring to.

You need to be doing a little more research yourself between asking
questions rather than expecting the folks here to spoon feed you the
answers.

If you want to be spoon fed the answers, pay for commercial support.

If you want to learn something, use the pointers you are given to do
some research before you ask you next question.

You should probably also read this:
http://www.catb.org/esr/faqs/smart-questions.html

http://lmgtfy.com/?q=servlet+specification

Mark

> 
> On Sun, Aug 30, 2015 at 9:55 PM, Mark Thomas  wrote:
> 
>> On 29/08/2015 22:26, Sreyan Chakravarty wrote:
>>> Okay I have just started to use Realms and container managed
>> authentication
>>> and I am confused about as how to specify a home page.
>>
>> Go and read the Servlet spec for how FORM authentication works.
>>
>> Then read the section on how to specify security constraints.
>>
>> Mark
>>
>>
>>>
>>> Let me explain-:
>>>
>>> 
>>> TECHERS
>>> /teacher/success.jsp
>>> GET
>>> POST
>>> 
>>>
>>> Here the only resource protected is
>>>
>>> /teacher/success.jsp page
>>>
>>> Now what if I wanted to add more pages to protect like
>>>
>>> /teacher/upload.jsp
>>>
>>> Do I add another  to the same  ? Or
>>> do I create another web-resource collection for /teacher/upload.jsp?
>>>
>>> Also if they are in the same in the  how does
>>> Tomcat know to go to /teacher/success.jsp and not /teacher/upload.jsp ?
>>>
>>> I mean all forms will have "j_security_check" as action, so which page
>> do I
>>> go to after login if multiple pages are protected ?
>>>
>>> How do I say that success.jsp is the home page and all other pages are
>>> protected but not home pages ?
>>>
>>> Regards
>>> Sreyan Chakravarty
>>>
>>
>>
>> -
>> 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

Re: How do LockOutRealms work ?

[Mark Thomas]

On 31/08/2015 07:32, Ludovic Pénet wrote:
> I can't see what would be the risks with being able to explain "This account 
> is locked for X minutes"...

An attacker performing a brute force attack has zero knowledge. They
have to guess both user names and passwords. Telling an attacker an
account is locked tells them:
a) they have found a valid user so they can concentrate on the password.
b) their behaviour has been noticed

Must better to let a brute force attacker pound away at a locked account
wasting their resources and probably tripping additional security
measures (like an IP block) for the excessive failures than it is to
tell them what they need to do to keep the authentication system happy.

> I experienced situations where the user calls the first level service desk 
> and a ticket goes all its way to someone who can read the server logs and 
> understand the issue... Not exactly optimal.

I agree. That is why most organisations provide self-service password
reset options that are linked off the login page. After a few failed
attempts to login the user simple resets their password (within whatever
rules the organisation requires) and carries on.

> An option to trigger an exception with more details would be great.

The details are available in the logs.

I am -1 (for security reasons) on providing any information at all to
the end user as to why a login may have failed.

Mark


> 
> Ludovic
> 
> Le 30 août 2015 18:21:51 GMT+02:00, Mark Thomas  a écrit :
>> On 29/08/2015 21:51, Sreyan Chakravarty wrote:
>>> Is there any way I can tell the user that what number of login
>> attempt he
>>> is on ? While using the LockOutRealm any way to display his login
>> attempt
>>> on an html or jsp page ?
>>
>> With the LockOutRealm as currently written, no.
>>
>> If you extend it and write some custom code, yes.
>>
>> I'd think through the risks very carefully before you go down this
>> road.
>> Do the benefits to the users out-weight the additional security risks
>> this would create?
>>
>> Mark
>>
>>>
>>> On Mon, Aug 24, 2015 at 7:31 PM, Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>>
>>> Sreyan,
>>>
>>> On 8/23/15 2:54 PM, Sreyan Chakravarty wrote:
>> I am confused with the functioning of LockOutRealms in Tomcat.
>>
>> My questions are as follows-:
>>
>>
>> 1. Say user at IP 10.10.10.1 has reached the maximum number of
>> invalid login attempts and is locked out. Now say a user from
>> 10.10.10.2 attempts to login, will Tomcat stop him too since he is
>> trying to login for the first time ? If not then how does Tomcat
>> keep track of users that are locked out ? Via there IP's ?
>>>
>>> If you look at the code [1], you'll see that users are identified by
>>> username (or "identifier) and no other factors. So, if you get
>>> locked-out from 10.10.10.1, you will also be locked-out from
>>> 10.10.10.2. However, the lock-out information is not shared amongst
>>> cluster members, so the LockOutRealm really only protects a single
>>> member of a cluster.
>>>
>>> If you need "proper" user-locking, you'll want to mark the user as
>>> locked-out in a database or something. You could do that by extending
>>> LockOutRealm and taking some other action (such as marking a user as
>>> locked in a db) after the registerAuthFailure method completes.
>>>
>> 2. When a user is locked out what message is displayed ? Can I
>> display a custom HTML page when a user has been locked out ? In
>> other words how much control do I have over the lock out process
>> and what error messages are shown ?
>>>
>>> It depends upon the type of authenticator you are using. If you use
>>> the BasicAuthenticator or DigestAuthenticator, you'll get a 401
>>> response, and you can customize what page gets returned with a 401.
>> If
>>> you use a FormAuthenticator, you can customize the form-error-page.
>> If
>>> you are using an x509Authenticator, you cannot customize anything
>>> since the failure occurs at the SSL handshake level.
>>>
>>> In any case, there does not appear to be a way to tell that the user
>>> failed due to too-many-authentication-failures. You could request
>> such
>>> as feature, but I would personally think nobody would want to
>>> implement it... you don't want to leak-out any information about the
>>> authentication process if you don't have to. Failed login = failed
>>> login, without further clarification. For a truly secure system, the
>>> LockOutRealm should also probably waste some time when a locked-out
>>> user is found, to simulate the amount of time it takes to
>>> properly-authenticate the user and then fail.
>>>
>>> Hope that helps,
>>> -chris
>>>
>>> [1]
>>>
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/realm
>>> /LockOutRealm.java?view=markup


>> -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For