... h1. This page has some troubleshooting tips that are common to all J2EE agents
h3. List of Problems/Solutions and Links to Help
On this page:
* [Fully Qualified Domain Names Required. localhost and numeric IP address like 127.0.0.0 not allowed | #fqdn]
* [Chose "J2EE" as the profile name for your J2EE agent profile | #agent_profile_name_j2ee]
* [Redirect Errors or loops(browser redirect error message), though user seems logged in, can see User Edit page on AM UI console | #redirect_errors]
On other pages:
* [See the GlassFish troubleshooting page for details on glassfish | http://wikis.sun.com/display/OpenSSO/GlassFishAgentTrouble] which has some examples based on GlassFish server but can still give hints for solutions using other agents.
h3. {anchor:fqdn}Fully Qualified Domain Names Required. localhost and numeric IP address like 127.0.0.0 not allowed
PROBLEM:
At install time or configure time and in browser urls you try to use numeric values for IP addresses or IP names which are not Fully Qualified Domain Names
SOLUTION:
I see a lot of people that have questions since Access Manager and Policy Agents require
fully qualified domain name (FQDN) style of names for hostnames in URLs. It wont let you use simple hostnames like test1 or localhost in URLs. These instructions below might help if you are on a windows machine(unix folks can do similiar things).
Create an alias for localhost:
As a developer running on windows, usually when you are just tickering with an application server and application, you deploy it and access the application at http://localhost:8080. But for opensso, the agent wants a fully qualified domain name when it will later ask you for a host name for configuration, but unfortunately it will not accept "localhost" and you can not use simple domain names like just "test1". So here is what you can do. Create another alias for local host, and here are the steps I did and should be similiar in your environment.
--Go to C:\WINDOWS\system32\drivers\etc and open the hosts file in a text editor.
--Inside the hosts file it contains this line "127.0.0.1 localhost" and now I create another alias for localhost that looks like a fully qualified domain name. In my case I will choose an alias my.test.domain.com and add it as an alias to the hosts file. Modify the line in the hosts file so it looks like
"127.0.0.1 localhost my.test.domain.com". I think you can create any alias here as long as it is something similiar to this.
You need to do this before installing the opensso war file and before installing the agent, as both set ups need to refer to this host name. Yes, you will need to uninstall the opensso.war, and redeploy and do configurator again after adding new host alias if you have previously installed opensso.war.
So later when you access your applications that are running on your locally hosted application server, the URL will be something like http://my.test.domain.com:8080/myapplication instead of local host http://localhost:8080/myapplication, and of course instead of 8080 port then at whatever http port is associated with the new domain you create in order to run agent and sample app. This will all become clear when we are done installing everything.
h3. {anchor:agent_profile_name_j2ee}Chose "J2EE" as the profile name for your J2EE agent profile
PROBLEM:
When setting up the agent profile for your agent installtion, you chose to name the profile "J2EE".
For example if you use the famadmin CLI to create an agent profile like
-famadm create-agent -b moulder -t J2EEAgent -u amadmin -f mypwfile -D /export/home/mystuff/AMAgentConfigurationCopy.properties
NOTE: We need to verify that this problem is common, and if so then file an issue to try to resolve it and/or make sure it is captured in documents etc.
Symptoms:
Things dont work properly.
When trying to access http://agenthost.x.y:8080/agentapp I am redirected to a URL
{noformat:nopanel=true} @agent_host@:8080/agentapp" (yes with the @ signs){noformat} You see a URL value with "@" signs even though you have configured your agent, and for example have no such paramter with "@" in
AMAgent.properties or in AMAgentConfiguratiopn.properties or when looking at configuration on central server.
Note, just FYI, when an agent is configured, some of the property values, especially ones related to URLs, use the "@" symbol as a delimiter in the blank template of an agent, and then these values delimited by "@" are swapped for real configuration values like the real host name or port ect that you provide. So if you see a bunch of values for url properties in your agent configuration, that might mean that your agent is not properly configured.
Another test, to try to verify if this is your problem, take a look at the configuration values for your agent profile and see if it has values with the "@" symbol even though you already supplied real values. One way to look at the values is to use the famadmin CLI to show an agents configuration, such as
{noformat:nopanel=true}
famadm show-agent -b j2eeagent -u amadmin -f mypwfile
and then you will see some properties such as
com.sun.identity.agents.config.login.url[0]=http://opensso.init8.net:8080@AM_SERVICES_DEPLOY_URI@/UI/Login
{noformat}
SOLUTION:
Create a new profile with a different name, as apparently "J2EE" is a reserved named.
h3. {anchor:redirect_errors}Redirect Errors or loops(browser redirect error message), though user seems logged in, can see User Edit page on AM UI console
_PROBLEM:_
Sometimes (this problem happens randomly/occassioanly but not all the time) when you have the agent and the Access Manager(AM) server running on the same machine, when you have an agent-protected application(like maybe the sample application that comes bundled with the agents) deployed, and when clicking thru the application on a protected page, the user is sent to the am login page and enters the username and password properly and clicks submit .... then instead of being sent back to the protected application page, you get a browser error (some browsers will say that a redirect error has occured -message differs depending on the browser) or maybe are sent to the Edit User page of AM server UI console, and if you then manually type in the opensso console UI URL (http://hostname:port/am or http://hostname:port/opensso depending on server being used)in the browser url box then you are taken to the opensso server Edit User page and can see that the user actually did successfully login to opensso server. But for some reason you did not get redirected back to your agent-protected application.
You can test if you have this issue by trying the scenario described in this problem section, and then going to the opensso UI console to check if user was successfully logged, even though browser says you have an error. Do you see the User Edit Page? SIDE NOTE: When a user is logged in to the access manager, even if they log in through an application that redirected then to AM login page, once they successfully login, if they type the opensso console UI URL in browser tehn they will see the user profile of the logged in user. Each user can see there own user profile, and when logged in can edit it. So if you can see the User Edit page for the user you logged in as, then this means login was successful. If desired, you can click logout on the user Edit page so this user is no longer logged in.
When things are working properly, a user who is usin an agent-protected application, when clicking on a protected page(resource), the user will be redirected to Access Manager/ opensso server login page, and upon entering proper username & password will be logged in, and then redirected back to the application they were using (and if enter AM/opensso server UI console URL dierctly in broser will see User Edit page to). But for some reason, occassionally there is a redirect error and you dont get sent back to your application.
Later, it would be nice to post some log files that get logged to make it easier to identify when you have this error.
This issue seems mostly relevant to Policy Agents 2.2 and AM 7.1 server. Newer versions have a fix.
_SOLUTION:_
This solution seems to work. Try to set the following property to true in the configuration of the opensso/fam/AM server.
{noformat}
com.iplanet.am.cookie.encode=true
{noformat}
By default it is set to false. You will have to restart the Access Manager/opensso server domain for this property to take effect, I think. |
... {noformat}
com.sun.identity.agents.config.sso.decode=false
{noformat}
Note, for opensso build 3 J2EE Policy Agents we will set this property to false by default so soon you wont experience this problem if you are using FAM/opensso server build 3 or later and J2EE Policy Agents build 3 or later.
How to change the agent property?
* For J2EE policy agents 2.2 edit the AMAgents.property file for this property.
* For J2EE policy agents 3.0 build 2 or earlier, if you chose to have Local agent configuration, then just edit the AMAgentConfiguration.properties file.
* For J2EE policy agents 3.0 build 2 or earlier, if you chose to have centralized agent configuration -the new style-, then use the opensso/FAM console UI to edit this property. Log in to opensso server as amAdmin, go to configurations tab, then agents tab, then j2ee tab and with j2ee tab page click on the agent name you previously created and now listed in page, then click on the SSO tab, then at bottom of page is decode property, make sure the property is NOT enabled(so not checked)
*For (build 3 and later) Policy Agents 3.0 and fam/opensso 8.0 a partial fix was added to the server and with 3.0 agents having decode=false as default, so you should not see it anymore.
See [
https://opensso.dev.java.net/issues/show_bug.cgi?id=843] if interested in tracking this issue. |