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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
