Sorry. Wrong mailing list. On Wed, Dec 2, 2009 at 5:00 PM, Shaun Senecal <ssenecal.w...@gmail.com> wrote: > 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
