tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shaun Senecal <ssenecal.w...@gmail.com>
Subject RE: j2ee agent session notification breaks agent realm function
Date Wed, 02 Dec 2009 08:00:18 GMT
I am actually having the exact same problem.  Were you ever able to
resolve this?  If I change my setup to use polling on a short interval
then I am able to logout and subsequently log back in (as long as the
user waits long enough for the poll interval).

My DA server and my OpenSSO server are installed on the same physical
hardware, but in separate Tomcat 6 containers.  My setup includes
having the Policy Agent behind a load balancer, so the setup looks
something like:

VIP: support.company.com:443
OpenSSO: server1.company.com:8443
DA: server1.company.com:3443 (same hardware, diff container)
Policy Agent: server2.company.com:8443

If I access the Policy Agent directly
(https://server2.company.com:8443) I can login and logout as many
times as I want.  However, if I access via the VIP
(https://support.company.com:443) then I can only login and logout
once.  As soon as I try to login again, I end up with an exception in
my debug.log and a 403 accessing j_security_check.  Hoping someone
made some headway on this one.

The exception I see in my log file is:

SSOTokenValidator: validate failed with exception
[AgentException Stack]
com.sun.identity.agents.arch.AgentException: Invalid transport string
        at com.sun.identity.agents.util.TransportToken.<init>(TransportToken.java:96)
        at com.sun.identity.agents.common.SSOTokenValidator.validate(SSOTokenValidator.java:99)
        at com.sun.identity.agents.realm.AmRealm.authenticate(AmRealm.java:141)
        at com.sun.identity.agents.tomcat.v6.AmTomcatRealm.authenticate(AmTomcatRealm.java:103)
        at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:258)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:417)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at com.tradingscreen.tomcatutils.authenticator.SingleSignOn.invoke(SingleSignOn.java:64)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
        at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:883)
        at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:722)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2214)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)









They are on separate containers on physically separate servers.

Cheers,

Scott

-----Original Message----- From: Hua....@Sun.COM
[mailto:Hua....@Sun.COM] Sent: Tuesday, 10 March 2009 01:44 To:
use...@opensso.dev.java.net Subject: Re: j2ee agent session
notification breaks agent realm function

I am not sure if you have the agent and distauth installed on the same
container (I noticed they use different protocols and ports.) Please
be aware that having them on the same container is not a supported
configuration.

Thanks, Hua

Damien Covey wrote:

If I log out using the registered logout url (
/agentsample/logout.html ) it works as expected, that is I'm granted
access on the next login.

However if I log out directly at daui (or opensso) I am denied access
at next login.

On Mon, March 9, 2009 16:56, Subba Evani wrote:

Yes, please do.

-Subba

Damien Covey wrote:

Changing to com.sun.identity.agents.config.logout.uri[agentsample] =
/agentsample/logout.html worked. Accessing that url logs out of
OpenSSO.

Shall I give that a go with
com.iplanet.am.session.client.polling.enable=false and see if that
changes anything?

On Mon, March 9, 2009 16:48, Subba Evani wrote:

Actual physical resource not really required, but give it a try. Are
you accessing the logout url in the same browser window where user
logged in?

Thanks, Subba

Damien Covey wrote:

No, the user is definately not logged out. The actual page configured
there does not exist. By dummy physical resource do you mean I should
create an empty logout.html and configure it as the logout URI?

On Mon, March 9, 2009 16:33, Subba Evani wrote:

Is user getting logged out ok? Try with a dummy physical resource like
logout.html.

Thanks, Subba

Damien Covey wrote:

com.sun.identity.agents.config.logout.uri[agentsample] =
/agentsample/logout is already set on the agent. When I request this
url in the browser http://sso.domain.com/agentsample/logout I recieve
a HTTP404.

On Mon, March 9, 2009 15:45, Subba Evani wrote:

Could you try with agent logout feature (define a logout uri say
/agentsample/logout.html in J2EE Agent -> Application -> Logout URI
processing) and see if there is any difference.

Thanks, Subba

Damien Covey wrote:

We've run into an issue with the OpenSSO agent for Tomcat (6.0.14).

When we have notification set for polling, that is;
com.iplanet.am.session.client.polling.enable=true Access to our
application works as expected. When we set
com.iplanet.am.session.client.polling.enable=false access to the
application is blocked on re-login.

We're running our 'test case' using the agentsample application
bundled with the agent.

Here's the scenario with polling enabled; 1. Access
http://sso.domain.com/agentsample/securityawareservlet (recieve
jsessionid cookie) 1a (redirect to authentication) 2. Authenticate at
daui https://sso.domain.com/distAuth/UI/Login 2a (redirect to
protected resource from 1.) 3. Access
http://sso.domain.com/agentsample/securityawareservlet (present
existing jsessionid cookie) 3a. Redirected to j_security_check (with
new jsessionid cookie) 4-> access allowed continue 5. In another
window log out https://sso.domain.com/distAuth/UI/Logout 5a.
iPlanetDirectoryPro cookie set to "LOGOUT" 6. Access
http://sso.domain.com/agentsample/securityawareservlet (original
jsessionid presented) 6a. Redirect to auth 7. Authenticate at daui
https://sso.domain.com/distAuth/UI/Login 7a (redirect to protected
resource from 1.) 8. Access
http://sso.domain.com/agentsample/securityawareservlet
(present/existing existing jsessionid cookie) 8a. Redirected to
j_security_check (with new jsessionid cookie) 9 -> access allowed
continue

With polling disabled; 1. Access
http://sso.domain.com/agentsample/securityawareservlet (recieve
jsessionid cookie) 1a (redirect to authentication) 2. Authenticate at
daui https://sso.domain.com/distAuth/UI/Login 2a (redirect to
protected resource from 1.) 3. Access
http://sso.domain.com/agentsample/securityawareservlet (present
existing jsessionid cookie) 3a. Redirected to j_security_check (with
new jsessionid cookie) 4-> access allowed continue 5. Log out
https://sso.domain.com/distAuth/UI/Logout 5a. iPlanetDirectoryPro
cookie set to "LOGOUT" 6. Access
http://sso.domain.com/agentsample/securityawareservlet (original
jsessionid presented) 6a. 403 Access denied returned (expect a
redirect to Authenticate)

This seems like a bug to do with notifications. Is anyone else seeing
this and maybe have a resolution for it?

I'll head over to the issue tracker and report this there if no one
else is having similar issues.

Thanks

-- Damien

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: user...@opensso.dev.java.net For additional
commands, e-mail: user...@opensso.dev.java.net

This e-mail is sent by Suncorp-Metway Limited ABN 66 010 831 722 or one of its
related entities "Suncorp". Suncorp may be contacted at Level 18, 36
Wickham Terrace, Brisbane or on 13 11
55 or at suncorp.com.au. The content of this e-mail is the view of the
sender or stated author and does
not necessarily reflect the view of Suncorp. The content, including attachments,
is a confidential communication between Suncorp and the intended recipient. If
you are not the intended recipient, any use, interference with, disclosure or
copying of this e-mail, including attachments, is unauthorised and expressly
prohibited. If you have received this e-mail in error please contact the sender
immediately and delete the e-mail and any attachments from your
system. If this e-mail constitutes a commercial message of a type that
you no longer
wish to receive please reply to this e-mail by typing Unsubscribe in the subject
line.

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


Mime
View raw message