You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Morrison <mo...@gmail.com> on 2009/11/11 20:11:35 UTC
Token Security
Hi,
I've been asked to put some security in place for a website, at the moment
there are two requirements with a possible extension;
1) The referer must be XXX (configurable)
2) There must be a token passed either GET or POST in the URL which
matches some internally generated code.
The possible extension would be the token passed in would be sent to
(another) webserver for validation.
I've been looking at this, and I *think* that I need to add a JAAS realm,
but I can't work out how to not have a login page. The security must deny
access unless the above is matched.
I've seen reference to where auth-method can be NONE which I assume is
right (since none of the others are) but am at a loss as to how to get
this to work.
Thanks for any advice or pointers to documentation.
Regards,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by Joseph Morgan <jo...@ignitesales.com>.
SAML doesn't require JAVA, and is XML (a place where MS is strong)... but since it is XML, can be handled well by Java
-----Original Message-----
From: John Morrison [mailto:morrijr@gmail.com]
Sent: Thursday, November 12, 2009 8:18 AM
To: users@tomcat.apache.org
Subject: RE: Token Security
On Thu, November 12, 2009 1:33 pm, Joseph Morgan wrote:
> John,
>
> Just curious, but have you looked into existing token-based security
> mechanisms such as LTPA (if you're predominantly an IBM shop) or SAML?
Hi Joseph
I haven't to be honest; this isn't a java shop. MS is 99% of what we use
but a tool was dictated which requires java so...
To be honest, the managers know what they'll get isn't really secure, I've
made it plain enough. But it's all they are willing to give us time to
implement.
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by Joseph Morgan <jo...@ignitesales.com>.
Ahhhhhh Mr. Morrison... you disappoint me! After the "trial" and as they're walking you out, they'll be so nicely explaining to you how you "should've" done more to protect the interests of the company....
-----Original Message-----
From: John Morrison [mailto:morrijr@gmail.com]
Sent: Thursday, November 12, 2009 8:43 AM
To: Tomcat Users List
Subject: RE: Token Security
Nope. I've made it clear (and I've the email trail to prove) that I'm
doing this this way solely at the order of the powers that be.
On Thu, November 12, 2009 2:31 pm, Joseph Morgan wrote:
> And let me guess... the day a costly security breach occurs, they'll be
> escorting you out???
>
> -----Original Message-----
> From: John Morrison [mailto:morrijr@gmail.com]
> Sent: Thursday, November 12, 2009 8:18 AM
> To: users@tomcat.apache.org
> Subject: RE: Token Security
>
> On Thu, November 12, 2009 1:33 pm, Joseph Morgan wrote:
>> John,
>>
>> Just curious, but have you looked into existing token-based security
>> mechanisms such as LTPA (if you're predominantly an IBM shop) or SAML?
>
> Hi Joseph
>
> I haven't to be honest; this isn't a java shop. MS is 99% of what we use
> but a tool was dictated which requires java so...
>
> To be honest, the managers know what they'll get isn't really secure,
> I've
> made it plain enough. But it's all they are willing to give us time to
> implement.
>
> J.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by John Morrison <mo...@gmail.com>.
The product manager has said do it that way
His boss has said do it that way
My boss's boss has said do it that way
And I've got the emails to prove it ;)
On Thu, November 12, 2009 3:08 pm, Joseph Morgan wrote:
> Did I just hear... "D--- the torpedos!"
>
> -----Original Message-----
> From: John Morrison [mailto:morrijr@gmail.com]
> Sent: Thursday, November 12, 2009 9:04 AM
> To: users@tomcat.apache.org
> Subject: RE: Token Security
>
> Thanks guys, I've got what I needed working. Most appreciated.
>
> Regards,
>
> John.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by Joseph Morgan <jo...@ignitesales.com>.
Did I just hear... "D--- the torpedos!"
-----Original Message-----
From: John Morrison [mailto:morrijr@gmail.com]
Sent: Thursday, November 12, 2009 9:04 AM
To: users@tomcat.apache.org
Subject: RE: Token Security
Thanks guys, I've got what I needed working. Most appreciated.
Regards,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by John Morrison <mo...@gmail.com>.
Thanks guys, I've got what I needed working. Most appreciated.
Regards,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by John Morrison <mo...@gmail.com>.
Nope. I've made it clear (and I've the email trail to prove) that I'm
doing this this way solely at the order of the powers that be.
On Thu, November 12, 2009 2:31 pm, Joseph Morgan wrote:
> And let me guess... the day a costly security breach occurs, they'll be
> escorting you out???
>
> -----Original Message-----
> From: John Morrison [mailto:morrijr@gmail.com]
> Sent: Thursday, November 12, 2009 8:18 AM
> To: users@tomcat.apache.org
> Subject: RE: Token Security
>
> On Thu, November 12, 2009 1:33 pm, Joseph Morgan wrote:
>> John,
>>
>> Just curious, but have you looked into existing token-based security
>> mechanisms such as LTPA (if you're predominantly an IBM shop) or SAML?
>
> Hi Joseph
>
> I haven't to be honest; this isn't a java shop. MS is 99% of what we use
> but a tool was dictated which requires java so...
>
> To be honest, the managers know what they'll get isn't really secure,
> I've
> made it plain enough. But it's all they are willing to give us time to
> implement.
>
> J.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by Joseph Morgan <jo...@ignitesales.com>.
And let me guess... the day a costly security breach occurs, they'll be escorting you out???
-----Original Message-----
From: John Morrison [mailto:morrijr@gmail.com]
Sent: Thursday, November 12, 2009 8:18 AM
To: users@tomcat.apache.org
Subject: RE: Token Security
On Thu, November 12, 2009 1:33 pm, Joseph Morgan wrote:
> John,
>
> Just curious, but have you looked into existing token-based security
> mechanisms such as LTPA (if you're predominantly an IBM shop) or SAML?
Hi Joseph
I haven't to be honest; this isn't a java shop. MS is 99% of what we use
but a tool was dictated which requires java so...
To be honest, the managers know what they'll get isn't really secure, I've
made it plain enough. But it's all they are willing to give us time to
implement.
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by John Morrison <mo...@gmail.com>.
On Thu, November 12, 2009 1:33 pm, Joseph Morgan wrote:
> John,
>
> Just curious, but have you looked into existing token-based security
> mechanisms such as LTPA (if you're predominantly an IBM shop) or SAML?
Hi Joseph
I haven't to be honest; this isn't a java shop. MS is 99% of what we use
but a tool was dictated which requires java so...
To be honest, the managers know what they'll get isn't really secure, I've
made it plain enough. But it's all they are willing to give us time to
implement.
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by Joseph Morgan <jo...@ignitesales.com>.
John,
Just curious, but have you looked into existing token-based security mechanisms such as LTPA (if you're predominantly an IBM shop) or SAML?
-----Original Message-----
From: John Morrison [mailto:morrijr@gmail.com]
Sent: Wednesday, November 11, 2009 1:12 PM
To: users@tomcat.apache.org
Subject: Token Security
Hi,
I've been asked to put some security in place for a website, at the moment
there are two requirements with a possible extension;
1) The referer must be XXX (configurable)
2) There must be a token passed either GET or POST in the URL which
matches some internally generated code.
The possible extension would be the token passed in would be sent to
(another) webserver for validation.
I've been looking at this, and I *think* that I need to add a JAAS realm,
but I can't work out how to not have a login page. The security must deny
access unless the above is matched.
I've seen reference to where auth-method can be NONE which I assume is
right (since none of the others are) but am at a loss as to how to get
this to work.
Thanks for any advice or pointers to documentation.
Regards,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Token Security
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John,
On 11/11/2009 5:01 PM, John Morrison wrote:
> I've not come across filters before - I'll look into them in more depth at
> work tomorrow, however could you expound upon how you would envisage it
> working?
The filter simply checks your requirements before allowing access to a
particular resource.
> Does the filter cover all the resources, because once the user token has
> been verified I wasn't going to pass it around anymore...?
One way to do this would be to put a either the token itself or
something else (like a simple Boolean flag) into the user's session that
indicates that they have passed the "token test" at some point.
Your filter can check for either the session token or one in the
incoming request.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr8GPkACgkQ9CaO5/Lv0PA0xACePS1i+iftVjJX/EwlgJnV8n9y
rHoAoIwhebLlWHqnkuRYQSr6OgnyGLJ3
=ZdlP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Token Security
Posted by John Morrison <mo...@gmail.com>.
On Wed, November 11, 2009 9:51 pm, Mark Thomas wrote:
> John Morrison wrote:
>> Hi,
>>
>> I've been asked to put some security in place for a website, at the
>> moment
>> there are two requirements with a possible extension;
>>
>> 1) The referer must be XXX (configurable)
>> 2) There must be a token passed either GET or POST in the URL which
>> matches some internally generated code.
>>
>> The possible extension would be the token passed in would be sent to
>> (another) webserver for validation.
>>
>> I've been looking at this, and I *think* that I need to add a JAAS
>> realm,
>> but I can't work out how to not have a login page. The security must
>> deny
>> access unless the above is matched.
>
> I'd just use a filter.
>
> Mark
Hi Mark,
I've not come across filters before - I'll look into them in more depth at
work tomorrow, however could you expound upon how you would envisage it
working?
Does the filter cover all the resources, because once the user token has
been verified I wasn't going to pass it around anymore...?
Thanks for the reply,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Token Security
Posted by Mark Thomas <ma...@apache.org>.
John Morrison wrote:
> Hi,
>
> I've been asked to put some security in place for a website, at the moment
> there are two requirements with a possible extension;
>
> 1) The referer must be XXX (configurable)
> 2) There must be a token passed either GET or POST in the URL which
> matches some internally generated code.
>
> The possible extension would be the token passed in would be sent to
> (another) webserver for validation.
>
> I've been looking at this, and I *think* that I need to add a JAAS realm,
> but I can't work out how to not have a login page. The security must deny
> access unless the above is matched.
I'd just use a filter.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Token Security
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John,
On 11/11/2009 5:29 PM, John Morrison wrote:
> Correct, at the moment there is no requirement to actually authenticate
> the user. However, I've been told to ensure that, if the client wishes
> (and pays) that the solution could be expanded to do so.
If you are looking for a more general solution, you could use
securityfilter (http://securityfilter.sourceforge.net) which allows you
to heavily customize the authentication process.
> Is this something like you are thinking;
>
> If the user has a session;
> let them access what they want
> else if the requested url has a param/value of [insert hash algor]
> set the user up with a session and let them access what they want
> else
> return Access Forbidden
>
> Is this possible in a filter?
This is definitely possible, but I wouldn't use the presence of a
session as your test; instead, I'd use the presence of a particular
key/value pair in the session attributes instead. Why? Tomcat's
container-managed authentication creates a session for the user before
they have been authenticated. Also, any JSP that accidentally didn't
mention session="false" in its header will create a session. In either
case, your users would be allowed inappropriate access.
How about this:
If the user has a session and they have a valid token in the session
allow access
else if the request contains a valid token
place token in session
allow access
else
disallow access
>> You could always make your login page just look like a "Forbidden" page.
>> There's nothing that says a login page has to contain a login form :)
>
> *grin* point, however doesn't the login page get displayed before the
> LoginModule is called?
Yes, but if you've already allowed access (because no interactive
credentials are required), the login page should never be shown, right?
Anyone who sees a login page didn't send a proper token along with their
request, and should end up seeing the "login" page which just says "go
away". I'm not entirely sure how JAAS works, but this sounds reasonable
to me.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr8Gn4ACgkQ9CaO5/Lv0PDlcgCguLWaGLMueC4Cin0JCa7vpEf6
rlQAni0A6R0FaTwiuLSJ77oSy7eews+C
=Vwv+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by John Morrison <mo...@gmail.com>.
On Thu, November 12, 2009 1:49 pm, Joseph Morgan wrote:
>>Correct, at the moment there is no requirement to actually authenticate
>>the user. However, I've been told to ensure that, if the client wishes
>>(and pays) that the solution could be expanded to do so.
>
> I may have missed something, but are you simply trying to ensure secondary
> requests to web pages/resources/objects/whatever came through a singular
> entry point? That is, someone comes in to your web world but needs to
> visit Page A before requesting other pages/resources on the site?
That wouldn't be my aim; I personally dislike 'landing' pages, but it
might be a consequence :(
>>Is this something like you are thinking;
>>
>>If the user has a session;
>> let them access what they want
>>else if the requested url has a param/value of [insert hash algor]
>> set the user up with a session and let them access what they want
>>else
>> return Access Forbidden
>
>>Is this possible in a filter? (My knowledge of them is currently 0;
>> I'll
>>read up on them in depth tomorrow)
>
> There is no security in this approach, even if you do authenticate the
> user up front (as guest or otherwise), unless this token is flying around
> across a secured protocol. A man in the middle can intercept the token
> and start issuing requests as the original user.
>
> The answer is, yes, a filter can be made to ensure the token is there and
> reject if not, but will the initial request (the one that issues the
> token) and subsequent requests be exchanged via SSL?
Yes, all access including authentication on both servers is https.
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Token Security
Posted by Joseph Morgan <jo...@ignitesales.com>.
>Correct, at the moment there is no requirement to actually authenticate
>the user. However, I've been told to ensure that, if the client wishes
>(and pays) that the solution could be expanded to do so.
I may have missed something, but are you simply trying to ensure secondary requests to web pages/resources/objects/whatever came through a singular entry point? That is, someone comes in to your web world but needs to visit Page A before requesting other pages/resources on the site?
>Is this something like you are thinking;
>
>If the user has a session;
> let them access what they want
>else if the requested url has a param/value of [insert hash algor]
> set the user up with a session and let them access what they want
>else
> return Access Forbidden
>Is this possible in a filter? (My knowledge of them is currently 0; I'll
>read up on them in depth tomorrow)
There is no security in this approach, even if you do authenticate the user up front (as guest or otherwise), unless this token is flying around across a secured protocol. A man in the middle can intercept the token and start issuing requests as the original user.
The answer is, yes, a filter can be made to ensure the token is there and reject if not, but will the initial request (the one that issues the token) and subsequent requests be exchanged via SSL?
Re: Token Security
Posted by John Morrison <mo...@gmail.com>.
Hi Christopher,
On Wed, November 11, 2009 10:07 pm, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> John,
>
> On 11/11/2009 2:11 PM, John Morrison wrote:
>> 1) The referer must be XXX (configurable)
>> 2) There must be a token passed either GET or POST in the URL which
>> matches some internally generated code.
>
> I agree with Mark: a relatively simple Filter could be implemented that
> prohibits access unless the above requirements are met.
>
> These requirements don't really authenticate the user in any way, do
> they? Do you have to populate a Principal object in the request and then
> use that to do authorization? Or, do you just need to prevent
> unauthorized people from getting in?
Correct, at the moment there is no requirement to actually authenticate
the user. However, I've been told to ensure that, if the client wishes
(and pays) that the solution could be expanded to do so.
Is this something like you are thinking;
If the user has a session;
let them access what they want
else if the requested url has a param/value of [insert hash algor]
set the user up with a session and let them access what they want
else
return Access Forbidden
Is this possible in a filter? (My knowledge of them is currently 0; I'll
read up on them in depth tomorrow)
>> I've been looking at this, and I *think* that I need to add a JAAS
>> realm,
>> but I can't work out how to not have a login page. The security must
>> deny
>> access unless the above is matched.
>>
>> I've seen reference to where auth-method can be NONE which I assume is
>> right (since none of the others are) but am at a loss as to how to get
>> this to work.
>
> You could always make your login page just look like a "Forbidden" page.
> There's nothing that says a login page has to contain a login form :)
*grin* point, however doesn't the login page get displayed before the
LoginModule is called?
It's been a long time since I was active in the Apache world and I'm
afraid my Java skills are well out of date. Please be patient.
Regards,
John.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Token Security
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John,
On 11/11/2009 2:11 PM, John Morrison wrote:
> 1) The referer must be XXX (configurable)
> 2) There must be a token passed either GET or POST in the URL which
> matches some internally generated code.
I agree with Mark: a relatively simple Filter could be implemented that
prohibits access unless the above requirements are met.
These requirements don't really authenticate the user in any way, do
they? Do you have to populate a Principal object in the request and then
use that to do authorization? Or, do you just need to prevent
unauthorized people from getting in?
> I've been looking at this, and I *think* that I need to add a JAAS realm,
> but I can't work out how to not have a login page. The security must deny
> access unless the above is matched.
>
> I've seen reference to where auth-method can be NONE which I assume is
> right (since none of the others are) but am at a loss as to how to get
> this to work.
You could always make your login page just look like a "Forbidden" page.
There's nothing that says a login page has to contain a login form :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr7Na0ACgkQ9CaO5/Lv0PBXEwCeLFod/89YKZsX0vFjr4eGYC1X
+Z8AoI+Y+mK+4h/NORJ2LFmf1H/Rsf0Y
=J/bL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org