IBM Verify

 View Only
Back to discussions
Expand all | Collapse all

Error FBTOAU225E due to mismatch on CONSENT_FORM_VERIFIER

  • 1.  Error FBTOAU225E due to mismatch on CONSENT_FORM_VERIFIER

    Posted Fri November 05, 2021 10:00 AM
    Reply

    Whenever the macro @consent_form_verifier@ for the consent page is being executed…

     

    @CONSENT_FORM_VERIFIER@

    This macro is replaced with a unique identifier for the consent_form_verifier parameter value. The consent_form_verifier parameter value is automatically generated by the authorization server. The parameter name and value must not be modified.

     

    …it generates a random string and stores it temporarily somewhere in ISAM. Whenever the user clicks "I consent", the very same generated verifier is being sent to ISAM. ISAM then does a check if it matches the verifier that was initially generated on the consent page.

    For example:

    • If the macro generates consent_form_verifier="ABC" -> and then when clicking "I consent", you instead send something that differs, like consent_form_verifier="DEF", ISAM will present the error "FBTOAU225E The authorization delegate received a consent page form verifier that was not valid compared to the verifier in the user's session."

     What we have discovered is that when we use load balancing for oauth and load balancing for backend servers, i.e.:

     (proxy conf)

    [tfim-cluster:oauth-cluster]

    server = 9,https://example1/TrustServerWS/SecurityTokenServiceWST13

    server = 9,https://example2/TrustServerWS/SecurityTokenServiceWST13

     

    &

     

    (junction edit)

    Target backend server:

    Example1.testing.no

    Example2.testing.no

     

    …is that we run in to the same error "FBTOAU225E…"

     

    But we don't seem to have this problem when we use "Stateful junction" on the junction edit.

     

    I have verified that the initial verifier matches the one being sent in the post.

     

    Questions for IBM:

    • Where is the initial verifier populated by the macro actually being stored? In the user session somewhere?
    • Could it be that the verifier can be stored in multiple places thus giving us error when load balancing? If those places are not communicated with each other internally that is.

     

     



    ------------------------------
    Piyush Agrawal
    https://www.linkedin.com/in/piyush-norway/
    Gjensidige Norway
    ------------------------------


  • 2.  RE: Error FBTOAU225E due to mismatch on CONSENT_FORM_VERIFIER

    Posted Mon November 08, 2021 12:58 PM
    Reply
    Hi Piyush,

    I don't have a system like this set up to test but my guess is that that consent verifier value is stored in the "user session" of the AAC/Federation runtime.  By default, these user sessions are stored in an in-memory cache which would explain why you get a failure if the attempt to validate the verifier is made against a different instance of the AAC/Federation runtime than the one that created it.

    When you enable a stateful junction, this ensures that all (frontend browser) requests for a given session hit the same AAC/Fed runtime instance.  That would explain why enabling stateful junction avoids the problem.  This is probably the easiest, and most performant, solution to the issue if it is acceptable.

    It is possible to configure the user session to be stored in HVDB, DSC, or (in 10.0.2.0) in Redis.  In 10.0.2.0 there's a new "Session Persistence" page in the LMI to help you configure the options.  In earlier versions you have to configure by setting advanced configuration parameters.  Look for "session.store" and "distributedSessionCache.enabled".

    I hope this helps.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


Related Content