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.

i
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 =
/agentapp/sunwCDSSORedirectURI
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

http://usajssX.cds.disa.mil:8080

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] =
http://usajss18.satx.disa.mil:8080/amserver/cdcservlet
com.sun.identity.agents.config.cdsso.trusted.id.provider[1] =
http://usajss19.satx.disa.mil:8080/amserver/cdcservlet
com.sun.identity.agents.config.cdsso.trusted.id.provider[2] =
http://usajss20.satx.disa.mil:8080/amserver/cdcservlet

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.

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

Hello

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???

Regards

Hi,

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.

hth,
Sean

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.


HTH,

Vivek