J2EE agent and WebSocket connection failure

This topic contains 8 replies, has 2 voices, and was last updated by  tschoeller 4 months, 1 week ago.

  • Author
  • #24902

    I’m running AM 5.5.1 with the j2ee agent 3.5.1 and am trying
    to upgrade the agent to and the agent is getting an
    error upgrading to a WebSocket during an idp-initiated SSO.
    The logs indicate the SSO portion was successful, but the
    agent log is getting:

    WARNING: Failed to create new WebSocket connection, backing off
    org.forgerock.agents.notifications.websocket.WebSocketConnectionException: Failed to create connection
    at org.forgerock.agents.notifications.websocket.WebSocketConnectionImpl.<init>(WebSocketConnectionImpl.java:101)

    Caused by: javax.websocket.DeploymentException: The HTTP response from the server [404] did not permit the HTTP upgrade to WebSocket
    at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServerRecursive(WsWebSocketContainer.java:435)

    The request looks like:

    <entry method=”GET” url=”http://foo.bar.com:8081/openam/notifications”>

    <result>404 </result>

    <header>GET /openam/notifications HTTP/1.1</header>
    <header>Sec-WebSocket-Key: c30…yVLw==</header>
    <header>Connection: upgrade</header>
    <header>Sec-WebSocket-Version: 13</header>
    <header>Host: foo.bar.com:8081</header>
    <header>Upgrade: websocket</header>
    <header>iPlanetDirectoryPro2: GoMM_WFTzNgvLp3bwUjoKslXYkA.*AAJTSQA…*</header>
    <header>Sec-WebSocket-Protocol: v1.notifications.forgerock.org</header>


    8081 is the port for the Tomcat with AM.
    8080 is the port for the Tomcat with the j2ee agent.

    Using the older agent, 3.5.1, allowed the SSO to complete without
    running into this error.

    Windows 10 (amd64)
    AM 5.5.1
    j2ee agent
    Apache Tomcat
    JVM Version 1.8.0_60-b27


    The Websocket connection for J2ee isn’t as important as it is to WPA, but it should still be allowed.

    Is your agent pointing to a LB infront of AM? Check if websocket connections can be enabled and supported or as a test point the agent directly at one AM instance.


    But in my experience J2EE agent just gets Configuration updates through websockets, I’ve broken Tomcat before and had general login function, WPA though uses websockets more extensively.

    The other big difference with Agent 3.5x and 5.x is the new agent will try to send you back to the global realm. You maybe failing if you are trying to authenticate to a specific realm.


    As an example:

    Can you provide more details on the example, or the behavior to understand where this is failing?


    Thanks. Guess I got some more reading to do. I do not have an LB. From what I can tell from the logs, the idp does send over the sso and the logs on the sp says that the sso is successful. I’m just trying to align all the log files, time-stamp-wise, to get the full picture as to when things stop working. I’ve tried curl to get a token and poke directly at AM notifications endpoint and still get the 404. I’ll keep reading.


    I’m not seeing what I need in the Redirection and Conditional Redirection chapter. The situation I have is that I have already logged at the idp (another maching in my COT) and I’m being set to my sp, so I should already be “logged in.” So, I don’t think I need redirections to a login page. With the 3.5 agent, I was dropped into my application as already having been authenticated.


    Are you expecting to go to a specific realm or the global realm? Agent 5.x will by default try the global realm, the older agents would follow the realm defined.

    A HAR of the client flow would help to see what URL the Agent is directing you to. There should be an oauth authorize call (oauth2/authorize). Agent 5.x is an OAUTH agent, so if you have a token already you would still need to be upgraded to an OAUTH Token. This maybe where your getting redirected to a different realm and then failing.

    As a test you could also try with the Custom login since this would use a session cookie.


    My agent is configured to the global realm. Don’t know what HAR is, but here is a trace around the 404:

    “GET /openam/Consumer/metaAlias/subRealm/sp…
    “GET /openam/isAlive.jsp HTTP/1.1” 200 113
    “GET /openam/json/serverinfo/* HTTP/1.1” 200 482
    “POST /openam/json/realms/root/authenticate… HTTP/1.1” 200 151
    “GET /openam/json/serverinfo/version HTTP/1.1” 200 176
    “GET /openam/json/realms/root/agents/j2eeAgent HTTP/1.1” 200 10859
    “GET /openam/notifications HTTP/1.1” 404 1098
    “GET /openam/isAlive.jsp HTTP/1.1” 200 113
    “GET /openam/notifications HTTP/1.1” 404 1098
    “GET /openam/notifications HTTP/1.1” 404 1098
    “GET /openam/notifications HTTP/1.1” 404 1098
    “GET /openam/notifications HTTP/1.1” 404 1098
    “GET /openam/notifications HTTP/1.1” 404 1098
    “GET /openam/notifications HTTP/1.1” 404 1098
    “GET /openam/notifications HTTP/1.1” 404 1098
    “GET /openam/oauth2/authorize… HTTP/1.1” 302 –


    The concern is not where the agent exist, it’s where your user will authenticate.

    Will your user authenticate to a specific realm? We can’t see the full IDP call to see if it’s to a specific realm.

    By default the Agent will send the user to the global realm for the oauth2/authorize call. If you want the user to authenticate to a specific realm you would need As an example:


    At the idp, I do log into a specific realm:

    GET http://idp.example.com/openam-bapp/saml2/jsp/idpSSOInit.jsp
    GET http://idp.example.com/openam-bapp/UI/Login

    POST http://idp.example.com/openam-bapp/json/realms/root/realms/subRealm/authenticate

    GET http://sp.example.com/openam/Consumer/metaAlias/subRealm/sp
    GET http://sp.example.com/myAppLogin/
    GET http://sp.example.com:8081/openam/isAlive.jsp
    GET http://sp.example.com:8081/openam/json/serverinfo/*
    POST http://sp.example.com:8081/openam/json/realms/root/authenticate
    GET http://sp.example.com:8081/openam/json/serverinfo/version
    GET http://sp.example.com:8081/openam/json/realms/root/agents/j2eeAgent
    GET http://sp.example.com:8081/openam/notifications
    <404 returned here>
    GET http://sp.example.com:8081/openam/isAlive.jsp
    GET http://sp.example.com:8081/openam/oauth2/authorize

    Would I need a conditional url for each sub-realm?


    The agent’s user guide says that the conditional redirection is available for login and logout requests — but I’ve already authenticated at the idp and the sp has stated (in the federation log) that my SSO was successful. Are we thinking different meanings of “login request?”

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

©2019 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?