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.  ISVA 10.0.1 token endpoint and expect header

    Posted Fri March 12, 2021 05:23 AM

    Hi,

    We recently upgraded to ISVA 10.0.1 and experience a problem with clients using Microsoft  OWIN OIDC .Net framework.
    It seems like this framework is sending an aditional http header Expect: 100-continue to the token endpoint.
    As a result the token endpoint does not respond with an access token.

    It can be reproduced with curl:

    Without expect header: 
    curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=,client_secret=,grant_type=authorization_code=code=123,redirect_uri=http://localhost:3000" https://pointofcontact/mga/sps/oauth/oauth20/token

    -> token endpoint returns token

    With expect header:
    curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -H "Expect: 100-continue" {.. snip ..)

    -> token endpoint return blank response

    Is this expected behaviour or a defect?



    ------------------------------
    Øyvind Bergerud
    ------------------------------



  • 2.  RE: ISVA 10.0.1 token endpoint and expect header

    Posted Fri March 12, 2021 07:17 AM
    Hi Øyvind,

    What is the blank response?  Is it a 100-Continue message (which is what is supposed to come back when you send an Expect header) or is it a standard response but just with no body?

    In Verify Access 10.0.1, functionality was added to the Reverse Proxy so it can either forward "Expect" header to the backend server (for it to handle) or it can respond with "100-Continue" itself (to handle on behalf of backend server).

    Check the value of the proxy-expect-header parameter in [server] stanza.
    If set to "yes" perhaps the token endpoint is not handling well and you can fix by changing this parameter to "no" to let WebSEAL take care of it.

    @Scott Exton - I would expect our AAC backend to handle an "Expect" header correctly... do you know of any issue in this area?

    Jon.
    ​

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

    Original Message


  • 3.  RE: ISVA 10.0.1 token endpoint and expect header

    Posted Fri March 12, 2021 08:11 AM
    In previous version (v9) how does ISAM handle this Header?

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------

    Original Message


  • 4.  RE: ISVA 10.0.1 token endpoint and expect header

    Posted Fri March 12, 2021 08:17 AM
    Hi Joao,

    I believe that, in previous versions, WebSEAL will just wait when receiving an "Expects" header.  A standards-based HTTP client will timeout if it doesn't receive a 100-Continue and will send payload anyway.  So a delay (based on the timeout) is introduced but everything still works as expected.

    Jon.

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

    Original Message


  • 5.  RE: ISVA 10.0.1 token endpoint and expect header

    Posted Fri March 12, 2021 03:47 PM
    Jon,
     
    I haven't specifically tested the AAC runtime with an 'expect' header, but seeing as the HTTP level traffic is handled by the Liberty application server I can't imagine that it wouldn't handle the header correctly.  Your suggestion of changing the proxy-expect-header configuration entry is the correct next-step, just in case the junctioned application cannot handle the expect header.
     
    Thanks.
     
     
     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access
    IBM Master Inventor

     
     
     
     



    Original Message


  • 6.  RE: ISVA 10.0.1 token endpoint and expect header

    Posted Mon March 15, 2021 09:00 AM
    Hi,

    Thanks for the reply. 
    The body of the reply is empty, but when the server returns 400 bad request.

    Setting proxy-expect-header = no resolves the issue:

    With proxy-expect-header yes:
    ➜ curl -v -H 'Expect: 100-continue'  $token_endpoint --data-ascii "client_id=$client_id&client_secret=$client_secret&grant_type=client_credentials"
    * Trying ****
    * TCP_NODELAY set
    * Connected to **** (****) port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
    * ALPN, server did not agree to a protocol
    * SSL certificate verify ok.
    > POST /mga/sps/oauth/oauth20/token HTTP/1.1
    > Host: ************
    > User-Agent: curl/7.68.0
    > Accept: */*
    > Expect: 100-continue
    > Content-Length: 91
    > Content-Type: application/x-www-form-urlencoded
    >
    * Mark bundle as not supporting multiuse
    < HTTP/1.1 100 Continue
    < connection: Close
    < content-length: 0
    < date: Mon, 15 Mar 2021 09:58:58 GMT
    * We are completely uploaded and fine
    * Mark bundle as not supporting multiuse
    < HTTP/1.1 400 Bad Request
    < content-language: en-US
    < content-length: 0
    < content-type: application/json;charset=UTF-8
    < date: Mon, 15 Mar 2021 09:58:58 GMT, Mon, 15 Mar 2021 09:58:58 GMT
    < p3p: CP="NON CUR OTPi OUR NOR UNI"
    < access-control-allow-origin: *****
    < access-control-allow-methods: "POST,OPTIONS,GET"
    < access-control-allow-headers: "Origin, Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With"
    < access-control-max-age: 86400
    < x-frame-options: SAMEORIGIN
    < cache-control: no-store, no-cache=set-cookie
    < expires: Thu, 01 Dec 1994 16:00:00 GMT
    < strict-transport-security: max-age=86400; includeSubDomains; preload
    < pragma: no-cache
    < Set-Cookie: AMWEBJCT!%2Fmga!JSESSIONID=************; Path=/; Secure
    < Set-Cookie: lb=********=; path=/
    <
    * Closing connection 0
    * TLSv1.2 (OUT), TLS alert, close notify (256):


    With proxy-expect-header set to no:
    curl -v -H 'Expect: 100-continue' $token_endpoint --data-ascii "client_id=$client_id&client_secret=$client_secret&grant_type=client_credentials"
    * Trying *****:443...
    * TCP_NODELAY set
    * Connected to ***** (*****) port 443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
    * SSL certificate verify ok.
    > POST /mga/sps/oauth/oauth20/token HTTP/1.1
    > Host: ******
    > User-Agent: curl/7.68.0
    > Accept: */*
    > Expect: 100-continue
    > Content-Length: 95
    > Content-Type: application/x-www-form-urlencoded
    >
    * Mark bundle as not supporting multiuse
    < HTTP/1.1 100 Continue
    * We are completely uploaded and fine
    * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < content-language: en-US
    < content-type: application/json;charset=UTF-8
    < date: Mon, 15 Mar 2021 12:51:16 GMT
    < p3p: CP="NON CUR OTPi OUR NOR UNI"
    < transfer-encoding: chunked
    < access-control-allow-origin: ******
    < access-control-allow-methods: "POST,OPTIONS,GET"
    < access-control-allow-headers: "Origin, Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With"
    < access-control-max-age: 86400
    < x-frame-options: SAMEORIGIN
    < cache-control: no-store, no-cache=set-cookie
    < expires: Thu, 01 Dec 1994 16:00:00 GMT
    < strict-transport-security: max-age=86400; includeSubDomains; preload
    < pragma: no-cache
    < Set-Cookie: AMWEBJCT!%2Fmga!JSESSIONID=******; Path=/; Secure
    < Set-Cookie: lb=******=; path=/
    <
    * Connection #0 to host ****** left intact
    {"access_token":"*****","scope":"","token_type":"bearer","expires_in":***}%


    ------------------------------
    Øyvind Bergerud
    ------------------------------

    Original Message


Related Content