Forum Discussion

Davo_T_20783's avatar
Davo_T_20783
Icon for Nimbostratus rankNimbostratus
Mar 31, 2014

APM SSO config using Kerberos to Weblogic backend not supplying session id cookie on post authentication requests

Hi,

 

We have constrained delegation and kerberos authentication working using APM 11.2.0, however once authenticated, subsequent request the JSESSIONID is not being supplied in the F5 request to the weblogic service. The APM happily supplies the JSESSIONID on authentication but not thereafter.

 

Of course for each request Weblogic will then create another session, and another, and the app will break.

 

Could it be because the only way we could get APM to supply a Kerberos ticket with the SPNEGO OID rather than the default (F5) KRB5 OID, is to set "on 401 request only" that it won't send the JSESSIONID cookie either unless it gets a 401 response? That's certainly my suspicion at this stage - and only because I have compared a direct (not through F5) browser session using SPNEGO with the Weblogic app.

 

Thanks in advance for any advice.

 

David.

 

David.

 

10 Replies

  • Here is the APM documentation about the "Send Authorisation" - why does F5 force OID to be 1.2.840.113554.1.2.2 for the Always option? It just doesn't make sense. What I want the APM to do is use the SPNEGO OID for the "Always" option. "The Kerberos ticket is submitted in the HTTP Authorization header. The header value starts with the word Negotiate, followed by one space and a base64 encoded GSSIAPI token that contains the Kerberos ticket. If the request contains an Authorization header from the client browser, it is deleted. The options are defined here.•Always The Authorization header with a Kerberos ticket is inserted into every HTTP request whether or not it requires authentication; in other words, it is inserted preemptively. The Kerberos ticket GSSAPI representation uses KRB5 Kerberos 5 mechanism displays (OID 1.2.840.113554.1.2.2). Selecting Always results in the additional overhead of generating a Kerberos token for every request. Kerberos tickets are fetched for first request only for the user and then cached for up to the configured ticket lifetime, so that subsequent requests involve local processing only. •On 401 Status Code The BIG-IP system forwards the user's HTTP request to the web server first without inserting a new Authorization header; (any Authorization header from a browser is also deleted). If the server requests authentication by responding with a 401 status code, the BIG-IP system retries the request with the Authorization header. The Kerberos ticket GSSAPI representation uses the SPNEGO mechanism displays (OID 1.3.6.1.5.5.2). Selecting On 401 Status Code results in an additional BIG-IP system and server request round trip when authentication is required for the request. "
  • Just curious, but do you have an iRule or other logic applied that controls the production of a JSESSIONID cookie? The presence of a JSESSIONID cookie is not usually related to Kerberos, and is an application-specific thing. Kerberos uses an Authorization header in the request, which the SSO would produce. But a JSESSIONID cookie would need to be set by the server and received and relayed by the client.

     

  • The biggest difference between the two options (always or on 401), and besides frequency, is the format of the ticket (GSSAPI vs SPNEGO). I can almost certainly guarantee though, unless you've coded it to do so, that APM SSO is NOT handling the JSESSIONID cookie. If you perform a client side capture, or better watch the traffic on both sides of the proxy, you should see the JSESSIONID Set-Cookie header leave the server and make it all the way to the client. You should them see the client send subsequent requests with this cookie.

     

  • APM does indeed maintain a session with the client using its own cookie (MRHSession), but it does not store and forward the application's cookies. Have you performed a capture to watch the JSESSIONID leave the server on the server side of the proxy, and not pass through to the client on the client side of the proxy?

     

  • You said, "No iRules associated with the JSESSIONID in our implementation", but are there any iRules applied? Do you by chance have a custom HTTP profile applied? What happens in the tcpdump capture directly after the server sends the JSESSIONID Set-Cookie header?

     

  • Looks like it may be an APM problem. Support ticket raised with F5 and issue has been reproduced, now waiting for further investigation.

     

    • daboochmeister's avatar
      daboochmeister
      Icon for Cirrus rankCirrus
      Has there been further news on this? I appear to be experiencing the same issue ... though in our case, the JSESSIONID doesn't make it to the client even if we have a basically empty APM policy, no kerberos, not even any authentication involved. In fact, we go through 2 layers of F5 - an external tier running APM which proxies to an internal F5, which proxies to the real servers - and the JSESSIONID is in fact returned by the internal F5, it gets swallowed by the external F5 running APM, apparently.
  • Question about this configuration. When using the APM module of F5 to handle the Kerberos authentication what provider should be used within weblogic? If F5 will not be forwarding the request unless the user is Authorized then I would assume that maybe the only provider that needs to be registered in weblogic is the LDAP authentication provider to handle the authorization of the authenticated user. This is the process that would have taken place if we were using weblogic to handle the kerberos authentication.

     

    Any idea if this is the correct assumption? Any suggestions would be helpful.

     

  • Isaac_Noumba_68's avatar
    Isaac_Noumba_68
    Historic F5 Account

    Was this issue solved by F5 Support ? Do you have a Bug ID or what he a configuration issue ?

     

  • OM's avatar
    OM
    Icon for Nimbostratus rankNimbostratus

    Hello,

     

    did you get by any chance a workaround or solution from F5?? we are experiencing the same issue .

     

    thank you.

     

    O.