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?
Sorry, Konstantin, I thought I had already described that case: I've
just run it again to make absolutely sure... it definitely gets 403
status, which proves the security constraints are properly enforced when
a user is not authenticated.
The container that experiences the 403 has an error page handler for
that particular status. The error page handler is, of course,
specifically defined as permitted for GET requests from unauthenticated
users. The error page handler redirects the client browser away from the
secure container/webapp and back to the logon/menu "static" webapp.
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), but does not
associate the Session for the second webapp with the existing SSOEvent
instance.
As I said before, I can fix my system behaviour quickly be defining
login-config's in each webapp to define a completely redundant FORM
login handler. That will cause the Sessions to be associated with the
SSOEvent and my required (correct) timeout behaviour will undoubtedly
follow.
Before I make this change, I want to satisfy myself that the
NonLoginAuthenticator.authenticate method is working properly according
to the specification.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
