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:53 GMT
Sorry.  Wrong mailing list.

On Wed, Dec 2, 2009 at 5:00 PM, Shaun Senecal <ssenecal.work@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message