Redirect Loop Problem for Web Policy Agent?

Question

I followed the installation guide for an Apache Web Policy Agent, but it always results in an endless redirect loop between web and application server. Firefox says "The page isn't redirecting properly" and Chrome thinks that "This webpage has a redirect loop". The setup is an Apache 2 on port 80 with a small demo app and a Web Policy Agent, and a Tomcat 7 server on port 8080 with an OpenAM server (the former OpenSSO from Sun):

• App URL http://hostname.example.com:80/ (App and Agent, running on Apache 2.2.16)
• OpenAM Server URL http://hostname.example.com:8080/openam (running on Tomcat 7.0.12)

The Live HTTP Header Firefox plugin shows that the policy agent and the OpenAM server (i.e. the Apache and Tomcat servers) redirect to each other, although the server sets the SSO Token Cookie correctly. The name of the SSO Token Cookie has the default value "iPlanetDirectoryPro". Any idea how to solve the problem?

Bryner

Are both your agent and OpenAM server using the default cookie name? If there is a mismatch between the two you can get this behaviour. – Palla

Yes, both seem to use the default cookie name "iPlanetDirectoryPro". Maybe an encoding issue? – Bryner

Have you tried putting both in debug mode? The agent keeps thinking you're not logged in, you'll need to know why this is. Maybe debug level logging can give you more information about that. – Palla

Yes, the agent does produce any useful log information. The OpenAM log says "login success". – Bryner

And when inspecting the http headers, can you see the Set-Cookie coming in the response from OpenAM and being passed as Cookie in the next request to the agent server? – Palla

I think I used the wrong format for the agent debug level, all:5 seems to be correct (instead of just 5). But it still does not produce any useful log information. Yes, the http headers contain a Set-Cookie key. The value is Set-Cookie: iPlanetDirectoryPro=..; Path=/ – Bryner

Answer 1

After a whole week I finally figured it out, with the help of Stackoverflow and the OpenAM Mailing list. There were two main problems: missing log files and missing cookie domains. Installing the OpenAM server and the Web Policy Agent is difficult, there are a lot of log files and many different configuration options. If you select the wrong options, it won't work. It is impossible to make it work without knowing what is going on, which can only be determined by a suitable log file.

Missing Log for Web Policy Agent : The log level must be set in the "Java properties" files. There are two "Java Properties" files for the Web Policy Agent, OpenSSOAgentBootstrap.properties and OpenSSOAgentConfiguration.properties. The log and debug level which is named com.sun.identity.agents.config.debug.level can and must be defined in both (!) files, and it should be set to the high level, all:4 or all:5. The format is important. Even if you do this, the AgentConfiguration.properties file is only used when the agent is not working in centralized config mode. The profile must be set to "local".

Missing Cookie Domain: Do not forget to enter the right Cookie Domain during the setup of the OpenAM server in the beginning, or add it afterwards if it is missing. On the OpenAM server, go to Configuration > System > Platform and change the Cookie Domain Value to your domain (for instace .example.com) if it is missing. Otherwise the browser will lose your cookie during the redirect process. Somehow I had an empty entry for the cookie domain at the OpenAM server, I guess a forgot a dot (example.com instead of .example.com) so that it was invalid (or something like that).

This troubleshooting site was helpful to locate the problem.

Bryner

Is there troubleshooting site hosted in Forgerock. Sun sites are not available now – Belia

There is a troubleshooting site here: openam.forgerock.org/doc/webhelp/admin-guide/… – Bryner

0x4a6f4672 - In case you can write a blog on this it may help folks like me . I have tried to follow all the instruction but this is the last thing i got. I assume there is more to the setup ..ERROR AS BELOW.............java.lang.NullPointerException at com.sun.identity.agents.filter.CookieResetInitializer.getAgentCookies(CookieResetInitializer.java:101) com.sun.identity.agents.filter.SSOContext.initialize(SSOContext.java:70) – Belia

This mail defines my problem. lists.forgerock.org/pipermail/openam/2014-September/018607.html , but could not figure out the solution – Belia

If I add .example.com going over Configuration > System > Platform, login to OpenAM Console is no longer working. Any idea what is going wrong here? – Ledda

Answer 2

@0x4a6f4672, Your post was absolutely helpful . Some more to add to your answer. The following changes is what i had to do in the config to make it running, at-least getting it running it for alfresco.

com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)

Now you are not running the Agent in centralised mode but in local mode the setting which is specified for profile attribute can be only set via property file so add the following.

com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)

As told by 0x4a6f4672, it is difficult to debug and unless you are in local mode , so switch to local mode immediately and start tracing the logs and make the property changes accordingly.

Belia