On 14/10/11 04:04, Brian Burch wrote:
I will go quiet for a few days while I checkout 6.0.28 and get it to
build.
Phew! That took me longer than I expected I got 6.0.28 to build,
then ran all the unit tests, then debugged the SSO logic and started to
understand it.
Then I
On 13/10/11 05:29, Konstantin Kolinko wrote:
What happens when an non-authenticated user accesses one of those webapps?
It just rejects it with 403, or it should display a login form (and
authenticate him/her and create a SSO cookie), or redirect to another
webapp that has a login form?
On 13/10/11 11:39, Brian Burch wrote:
To summarise: the webapp's explicit timeout is not being honoured
because its web.xml does not define a login-config section. Therefore,
the webapp has defaulted to use the NonLoginAuthenticator - which
honours the existing SSO state (via the client cookie),
On 13/10/11 15:14, Brian Burch wrote:
I beleve the division of responsibilities between the AuthenticatorBase
abstract class and its extension classes is wrong. At the moment, it is
the responsibility of the concrete class authenticate methods to add the
Session to the existing SingleSignOnEntry
On 13/10/11 15:14, Brian Burch wrote:
On 13/10/11 11:39, Brian Burch wrote:
To summarise: the webapp's explicit timeout is not being honoured
because its web.xml does not define a login-config section. Therefore,
the webapp has defaulted to use the NonLoginAuthenticator - which
honours the
On 11/10/11 22:24, Christopher Schultz wrote:
I'm not an expert at SSO, nor have I ever used it on any of my
projects. All my answers should be considered suspicious :)
So, it looks like the Valve should *not* be expiring your SSO when the
static webapp's session expires. Can you confirm that
2011/10/12 Brian Burch br...@pingtoo.com:
I've successfully run a remote debugger session against the SingleSignOn
Valve while it is handling my timeout scenario.
Interestingly, the logic to handle the timeout of a single webapp is exactly
as I wanted it to be... only the specific Session is
On 12/10/11 12:51, Konstantin Kolinko wrote:
Something becomes clearer.
Remembering the session as associated with ssoid is performed by
SingleSignOn.associate(..) method. This method is called by
AuthenticatorBase class.
Those webapps with long living sessions - are they protected by
security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 10/12/2011 8:53 AM, Brian Burch wrote:
My tomcat 6.0.28 compiled class for AuthenticatorBase does not
match the 6.0.33 source code I am debugging with. The SSO Valve is
pretty much the same.
So get the source for 6.0.28:
On 12/10/11 12:35, Brian Burch wrote:
I've successfully run a remote debugger session against the SingleSignOn
Valve while it is handling my timeout scenario.
Interestingly, the logic to handle the timeout of a single webapp is
exactly as I wanted it to be... only the specific Session is
2011/10/12 Brian Burch br...@pingtoo.com:
OK, it now all makes some kind of sense. I've discovered that the Session
associated with the second webapp is never being associated with the SSO
instance created by the first webapp. However, the weird thing is that the
protected resources of the
I am using tomcat 6.0.28 (actually the 6.0.28-10ubuntu2 package) as a
standalone web server. I am getting timeout behaviour that sort-of makes
sense, but doesn't agree with the way I read the servlet spec.
I have associated the org.apache.catalina.authenticator.SingleSignOn
Valve with my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 10/11/2011 10:09 AM, Brian Burch wrote:
6. The user tries to refresh the second webapp's page after about
25 minutes, but the GET fails with 403 status and the explanation
access to resource has been denied. Apparently, the user's
On 11/10/11 16:27, Christopher Schultz wrote:
Thanks very much for your speedy and informative reply, Christopher.
While my question is fresh in your mind, I hope you will not mind too
much if I ask a couple of relevant questions to clarify your answers below.
-BEGIN PGP SIGNED
Brian Burch wrote:
...
But I am having trouble understanding the life cycle of a Session. If
the browser has navigated away from my static webapp container, into a
completely different webapp container, why does it still have an
associated Session?
Probably because the first webapp has no
2011/10/11 Brian Burch br...@pingtoo.com:
2. My root welcome page does an html redirect to a small webapp called
static, which has its own web.xml. The redirect is to a page which is
protected by a security contraint which requires a FORM-based login (this
server only has an SSL Connector
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 10/11/2011 12:35 PM, Brian Burch wrote:
OK, I think I understand the distinction you are making, which is
consistent with there being a Session array (rather than a simple
field) in the SingleSignOnEntry class.
I haven't looked at the
On 11/10/11 22:24, Christopher Schultz wrote:
Super thoughts, Chris, but thanks also to everyone else who has
commented. I really appreciate everyone's contributions because (until
now) I felt I was out there on my own, ignorant and stupid. It is
reassuring to find that my analysis is not
18 matches
Mail list logo
