IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  liberty maximum header size?

    Posted 10/25/19 09:52 AM
    Hi Community,

    In our docker environment, we have made our runtime container available through a webseal junction. This junctions sends the PAC to the junctioned server (=runtime)

    We notice that sometimes the user gets a HTTP/400 back from the runtime while performing a SAML authentication.

    Investigation shows that this happens when a (very) big PAC is sent to the runtime. It seems like the request goes over a (default?) limit which is set for request headers.

    Is there a default limit in the header size? And if so, what is it and can it be configured somehow?
    Anybody encountered similar issues?

    Kind regards

    ------------------------------
    Kristof Goossens
    ------------------------------


  • 2.  RE: liberty maximum header size?

    Posted 10/28/19 11:24 AM
    Hello Kristof,

    Out of curiosity what do you mean by a "(very) big PAC" ?  

    Thank you,

    ------------------------------
    Christophe Agostini
    ------------------------------



  • 3.  RE: liberty maximum header size?

    Posted 10/30/19 09:42 AM
    Hi Christophe,

    I see a PAC of 18768 bytes coming in.
    Tweaking the max-webseal-header-size parameter may solve this in some situations: my finding is that putting that one to 2048 makes the runtime to accept the request. The runtime obviously knows how to cope with the chopped headers.

    For our situation, the PAC is after that sent to a custom EAI, which is not taking the chopped headers into account and so the flow breaks at that point :-/


    ------------------------------
    Kristof Goossens
    ------------------------------

    Original Message


  • 4.  RE: liberty maximum header size?

    Posted 10/30/19 10:11 AM
    On a sidenote: it does not work by specifying max-webseal-header-size=0 in the [junction] stanza and defining a more specific value in the [junction:$junction] stanza.

    If you do that, traces show that the headers are not chopped into multiple headers.

    ------------------------------
    Kristof Goossens
    ------------------------------

    Original Message


  • 5.  RE: liberty maximum header size?

    Posted 11/07/19 10:38 AM

    Hi Kristof,

    I don't think there is anything in the AAC/Fed runtime that is limiting the size of the incoming headers.
    I believe it's using the defaults of IBM Liberty Server.

    https://openliberty.io/docs/ref/config/#httpEndpoint.html#httpOptions

    In this scenario I believe it's the limitFieldSize = 32768 (default, and also the maximum - similiar to traditional TFIM on WebSphere ND)

    When dumping out a support file, the server.xml in liberty_runtime_dump.zip does not explicitely state a value (so it would take the defaults)

    Do you know if this is specific to the docker deployment (have you had any chance to test it on non-docker)
    Is there 'anything' else in between your WebSEAL and the Fed/AAC runtime?  (don't know if on a docker deployment there is some load balancing component in the middle?)

    Do you the the HTTP 400's also being generated from the Fed trace.log's? 

    Grts,
    Hans



    ------------------------------
    HANS VANDEWEGHE
    ------------------------------



  • 6.  RE: liberty maximum header size?

    Posted 11/11/19 03:17 AM
    Hi Hans,

    It's interesting indeed that the default values seem higher than what seems required; yet when testing with smaller PACs, the issue seems not to occur. 

    We've done our setup in swarm and so there is indeed a loadbalancer in between. I don't think that one is causing issues, as it's also there to go to the EAI, where the headers come through as expected. I'll try to increase tracing on the runtime and see what that shows.

    Setting everything up in a non-docker context seems a bit hard, as we don't have such an environment (anymore) :)

    ------------------------------
    Kristof Goossens
    ------------------------------

    Original Message


Related Content