7 Replies Latest reply on Oct 22, 2007 4:09 PM by 807573

    Urgent Weblogic J2EE Agent 2.2 in CDSSO mode - help

      We are using WebLogic 8.1 SP4 and J2EE Agent 2.2 in CDSSO mode. When we try to login to AM. The browser gets redirected to Protected resource on Agent and then it gets redirected back to AM. The AM inturn redirect it to Agent (saying the user Session is valid). This creates an infinite Loop.

      I found following error in amFilter file:
      05/29/2007 06:51:20:171 PM PDT: Thread[ExecuteThread: '14' for queue: 'weblogic.kernel.Default',5,Thread Group for Queue: 'weblogic.kernel.Default']

      SSOTokenValidator.validate(): Exception caught

      com.iplanet.sso.SSOException: AQIC5wM2LY4SfcwNDlAgbD6dBHFUkJKpbPWX5t6UNp1Ki7I=@AAJTSQACMDI=# Illegal attempt to use a restricted token.^M

      at com.iplanet.sso.providers.dpro.SSOProviderImpl.createSSOToken(SSOProviderImpl.java:205)^M

      at com.iplanet.sso.SSOTokenManager.createSSOToken(SSOTokenManager.java:325)^M

      at com.sun.identity.agents.common.SSOTokenValidator.validateInternal(SSOTokenValidator.java:252)^M

      at com.sun.identity.agents.common.SSOTokenValidator.validate(SSOTokenValidator.java:157)^M

      at com.sun.identity.agents.filter.SSOTaskHandler.process(SSOTaskHandler.java:88)^M

      at com.sun.identity.agents.filter.AmFilter.processTaskHandlers(AmFilter.java:185)^M



      Does anybody knows where it is failing ?


        • 1. Re: Urgent Weblogic J2EE Agent 2.2 in CDSSO mode - help
          I've seen this similar error with the apache 2.2 agents for CDSSO. Did you find a solution? did anyone else?

          I'm curious if you set it up in high availability mode with a load balancer.
          • 2. Re: Urgent Weblogic J2EE Agent 2.2 in CDSSO mode - help
            We have a distributed JEs infrastructure here.

            The hosts have nodenames that differ from the Load balanced service name.

            I found that j2ee agents must have several things exactly right for CDSSO to function

            Here is a quick cheat we use. The time between the agent system and the AM hosts must be synchronized. We use the navy clocks for this on all systems.

            Sync your systems time with an atomic clock someplace. Using ntp as a
            daemon for unix hosts or setting up windows time synch on windows boxes.

            in our AMAgent.properties.

            com.sun.identity.agents.config.cdsso.enable = true
            com.sun.identity.agents.config.cdsso.redirect.uri =
            com.sun.identity.agents.config.cdsso.clock.skew = 100

            Clients access our service via https://sso.csd.disa.mil:443
            Spo the agents are configured using this data.

            however we have LB and SSL termination etc ... in front of the hosts installed as


            You will need to have one entry for every AM host you have using its real name port and protocol

            Such as this ....

            com.sun.identity.agents.config.cdsso.trusted.id.provider[0] =
            com.sun.identity.agents.config.cdsso.trusted.id.provider[1] =
            com.sun.identity.agents.config.cdsso.trusted.id.provider[2] =

            if your AM hosts are installed on a different host name or port than the agent sees... IE using port and or protocol redirection you must have the ignore naming services flag set or you will endlessly redirect.

            com.iplanet.am.naming.ignoreNamingService = true

            ********* NOTE *****************
            Do not put a trailing space after value as it will wind up being ignored in some cases and make you insane.
            • 3. Re: Urgent Weblogic J2EE Agent 2.2 in CDSSO mode - help
              genreally the ignore naming service thing takes care of those redirects in our env..

              the webagent value is

              com.sun.am.ignore.naming_service = true
              • 4. Re: Urgent Weblogic J2EE Agent 2.2 in CDSSO mode - help

                That's a gem of a post, lots of hidden, not so well documented parameters in there.

                The problem with the site is the hostname and the virutal server container were different. I put the agentRootURL=hostname in addition to the agentRootURL=resource and it's working.

                • 5. Re: Urgent Weblogic J2EE Agent 2.2 in CDSSO mode - help

                  I am using Tomcat 5.5 and J2EE Agent 2.2 in CDSSO mode (AM is 7.1) and facing the same problem as Vivek (same logs) When i try to login to AM the browser gets redirected to Protected resource on Agent and then it gets redirected back to AM. The AM inturn redirect it to Agent. This creates an infinite Loop.

                  has anyone solve this???

                  • 6. Re: Urgent Weblogic J2EE Agent 2.2 in CDSSO mode - help

                    I just got a similar error when using an agent on BEA 10. I am not in cdsso mode, I have mode set to ALL, but that probably doesnt matter. In my case, the problem was that I had my policy on my AM server incorrectly specified.
                    The resources I was trying to protect were running on a different port than I had entered as the rules for the policy. For example, I had http://my.test.domain.com:6948/agentsample/protectedservlet and I should have listed http://my.test.domain.com:7001/agentsample/unprotectedservlet which is the host:port where my agent was running.
                    I saw those exact error messages in this case, so it may be the same for you.
                    Go to your am server console and look at the policies that you created and make sure that you have the proper hostname and port etc for all the protected resources in your policy.

                    My browser did a bunch of redirect attenpts until it failed and in my agent's AMFilter.log I saw this error
                    SSOTokenValidator.validate(): Exception caught
                    com.iplanet.sso.SSOException: AQIC5wM2LY4Sfcztt1ZzMeAkMmO5QM2aF140lrnPR OxfNA=@AAJTSQACMDE=# Invalid session ID.AQIC5wM2LY4Sfcztt1ZzMeAkMmO5QM2aF140lrnPR OxfNA=@AAJTSQACMDE=#
                         at com.iplanet.sso.providers.dpro.SSOProviderImpl.createSSOToken(SSOProviderImpl.java:193)
                         at com.iplanet.sso.SSOTokenManager.createSSOToken(SSOTokenManager.java:322)
                         at com.sun.identity.agents.common.SSOTokenValidator.validateInternal(SSOTokenValidator.java:226)
                         at com.sun.identity.agents.common.SSOTokenValidator.validate(SSOTokenValidator.java:133)
                         at com.sun.identity.agents.filter.SSOTaskHandler.process(SSOTaskHandler.java:73)
                         at com.sun.identity.agents.filter.AmFilter.processTaskHandlers(AmFilter.java:172)
                         at com.sun.identity.agents.filter.AmFilter.isAccessAllowed(AmFilter.java:135)
                         at com.sun.identity.agents.filter.AmAgentBaseFilter.doFilter(AmAgentBaseFilter.java:66)
                         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
                         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3368)
                         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
                         at weblogic.security.service.SecurityManager.runAs(Unknown Source)
                         at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2117)
                         at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2023)
                         at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1359)
                         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
                         at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)

                    Anyways, I got exact same symptoms as you, so maybe you have same problem and can use the same solution to fix it.

                    • 7. Re: Urgent Weblogic J2EE Agent 2.2 in CDSSO mode - help
                      Hi Guys,
                      I am sorry. I forgot to mention that I resolved my issue. After searching around the opensso code, I found the problem was in the Access Manager. After putting my agent's host FQDN in the /etc/hosts file and /etc/inet/ipnodes file, the problem went away.

                      The issue here is that, with Cookie hijacking mode and CDSSO, the AM tries to verify (during Session validation), whether cookie is issued to the same Policy agent or not. It was failing because it couldn't find the hostname in DNS.